Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
Доброй ночи.
Вопрос скорее общий.
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?
Пример: нужно сделать транспонирование таблицы, из вертикальной таблицы (month, day_month, contract, sum) сделать что то вроде (month, contract, sum_1, sum2, ..., sum_31), т.е. раскидать суммы горизонтально в зависимости от дня месяца.
Я делаю это в лоб, что то вроде sum(decode(extract day from day_month,1,sum_1)) over (partition by contract) as sum_1 и так далее. Общий смысл думаю понятен.
Такой подход работает, сбоев не даёт, но я вижу, что это некрасиво. И думаю, что более опытный человек нашёл бы более изящное и логичное решение задачи.
Кто как улучшает свой код? Очевидный ответ - опыт. Но возможно кто то читает книги\youtube\сайты по улучшению "шаблонов" своего кода? Кто как двигается в этом направлении, помимо опыта?
Буду благодарен за конструктивные ответы.
21 июн 20, 01:25    [22154425]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
feagor
Member

Откуда: Москва
Сообщений: 255
Arists,

Pivot
21 июн 20, 02:29    [22154431]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
feagor,

спасибо, но мой вопрос скорее общий:)
Пример был дан только для того, чтобы показать, что я понимаю что код не самый лучший.
21 июн 20, 02:44    [22154432]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
Arists
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?

У улучшения кода есть два основных направления. Первое - сделать, чтобы он работал быстро. Для этого есть общие подходы оптимизации - не делать лишнего, думать над алгоритмами и т. п., и есть знание механики сервера: сначала Кайт и далее глубже и глубже. Второе - сделать так, чтобы этот код был хорош в сопровождении (как собственном, так и других). Для этого, пожалуй, лучший способ - практика работы на других языках. PL/SQL язык, прямо скажем, не самый продвинутый, а SQL вообще плохо подходит для сопровождения. Поэтому, варясь в их соку, легко привыкнуть к тому, что так и должно быть. А вот программируя на чём-то ещё и сравнивая - начинаешь думать, как бы и на PL/SQL сформулировать так, чтобы было не хуже других. И постепенно начинает получаться.
21 июн 20, 02:46    [22154433]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
softwarer,

Спасибо за ответ.
Мой вопрос скорее связан не с оптимизацией кода, а с шаблонами проектирования кода.
Попробую объяснить что имею в виду на примере: иногда читаю код других разработчиков. И после прочтения у меня чувство "Барак Обама NOT BAD". И задаю себе вопросы: 1) Понимаю ли я что делает код? Да, понимаю 2) Красиво сделано? Да, красиво 3) Смог бы я сделать эту задачу если бы передо мной её поставили? Да, смог бы 4) Сделал бы я задачу настолько красиво? Нет, скорее всего сделал бы более топорно. Правильно, но более топорно.

То есть, насколько я понимаю, у разработчика из моего примера было бОльшее количество шаблонов, из которых он выбирал когда писал код.

Ответом на свой вопрос я ожидал или ссылку на статью, или возможно ютуб видео или книги.
Тема примерно такая "лучшие шаблоны проектирования кода на PL\SQL".

Я понимаю, что здесь упор идёт на опыт + большее продумывание реализации задачи.
Но возможно есть какие-нибудь материалы, от которых можно отталкиваться.
21 июн 20, 03:22    [22154434]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5369
Arists
Я понимаю, что здесь упор идёт на опыт + большее продумывание реализации задачи.
Но возможно есть какие-нибудь материалы, от которых можно отталкиваться.


Ищем материалы 960-970 г.г. прошлого тысячилетия, на тему структорного/процедурного программирования.
Читаем, проникаемся.

<:o)
22 июн 20, 10:13    [22154960]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 1411
Arists
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?

Перестать писать код на pl/sql.
/thread
22 июн 20, 10:46    [22154988]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Michael Isaev
Member

Откуда:
Сообщений: 148
Arists,

1. Поищите в инете соглашения о наименованиях объектов

2. Работая с базой данных Oracle DB:

1. Где только возможно пишите код на SQL (65%)
2. Если вашу задачу нельзя выполнить на SQL, пишите на PL/SQL (25%), особенно с учетом компиляции в нейтив код.
3. Если вашу задачу нельзя выполнить на PL/SQL, пишите на Java (7%)
4. Если вашу задачу нельзя выполнить на Java, пишите на С (3%)

3. Очень редко осторожно применяйте объектные возможности Oracle DB и PL/SQL.

4. Хорошо освойте инструменты наблюдения за производительностью SQL, PL/SQL. Читайте больше литературы про оптимизацию запросов и операций с БД.

5. Если вы решили применять здесь паттерны GoF, GRASP, SOLID, то мимо. Только часть из этих принципов можно применять к PL/SQL.
24 июн 20, 18:29    [22156712]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Elic
Member [заблокирован]

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 29861
Michael Isaev
1. Где только возможно пишите код на SQL (65%)
2. Если вашу задачу нельзя выполнить на SQL, пишите на PL/SQL (25%), особенно с учетом компиляции в нейтив код.
3. Если вашу задачу нельзя выполнить на PL/SQL, пишите на Java (7%)
4. Если вашу задачу нельзя выполнить на Java, пишите на С (3%)
Если бы не было дурацких цифр, то первые два пункта можно было бы принять. А так антинаучный бред. Без обид...
24 июн 20, 18:41    [22156720]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
merch
Member

Откуда:
Сообщений: 167
Elic
Если бы не было дурацких цифр, то первые два пункта можно было бы принять.

В первом пункте тебе какая цифра не нравится? 6 или 5?
24 июн 20, 20:26    [22156790]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Elic
Member [заблокирован]

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 29861
merch
Elic
Если бы не было дурацких цифр, то первые два пункта можно было бы принять.
В первом пункте тебе какая цифра не нравится? 6 или 5?
Ты тоже хочешь казаться оцифрованным дурачком?
Здравый смысл (он же целесообразность) не измеряется процентами.
А те, кто пытаются его измерить, лишены его.
Более того, здравый смысл, зачастую, не играет существенной роли. Потому что представителю от бизнеса нужно поставить дебильную галочку в своё портфолио, чтобы перейти в другую контору и там ещё чего -нибудь развалить.
25 июн 20, 06:42    [22156895]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
merch
Member

Откуда:
Сообщений: 167
Elic, да нет, читаю книжку просто книгу школьную, пытаюсь разобраться, что есть числа, что есть цифры. А теперь ты меня совсем запутал((

А сообщение Микаэля Исаева похоже на выдержку из книги Тома Кайта, без пункта "зачем это вообще делать".
Про проценты, которые он добавил после каждого утверждения. Может он так оценил свои знания С, Java, pl/sql...
25 июн 20, 10:05    [22156980]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Michael Isaev
Member

Откуда:
Сообщений: 148
merch,

Проценты я поставил, чтобы начинающим был примерно понятен порядок (ну а Elic-а бомбануло и он излишне перевозбудился)

Сейчас бы я еще и Java выкинул бы из этого списка, сократив до SQL > PLSQL > C. Раньше Oracle засадил Java в Базу на волне хайпа (в Oracle DB 9 даже Java EE была или типа того), хотя она там не нужна от слова совсем.

Совет еще один и тривиальный - если параметры и переменные процедур/функций отображаются на поля таблиц, то их объвлять с типом поля table.field%type, а не PLSQL, чтобы при возможном изменении типа полей не искать ошибки, а просто перекомпилировать пакет и автоматом подхватить новые типы.

Совет общий для всех языков и тривиальный - часто используемые процедуры функции выделять в пакеты (обычно это какие-нить xxxx_utils)

Еще Сложные структуры не передавать как параметры процедур, но если передаешь, то передавай по ссылке (nocopy).

Совет общий - больше смотреть код других разработчиков и библиотек, например Alexandria (но не только)

С каждой версией Oracle и VM становятся умнее и могут оптимизировать автоматом то, что раньше делалось вручную и чему были посвящены баталии здесь и на других форумах. Поэтому еще раз совет - освоить все инструменты наблюдения за производительностью и профилирования.

Можно еще почитать доку и посмотреть код от Oracle в OeBS - там есть как хорошие примеры так и откровенно антипатерны.
25 июн 20, 12:04    [22157115]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
Michael Isaev
Раньше Oracle засадил Java в Базу на волне хайпа (в Oracle DB 9 даже Java EE была или типа того), хотя она там не нужна от слова совсем.

Она была бы там чертовски нужна, если бы нормально работала.
25 июн 20, 12:07    [22157117]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 1411
softwarer
Она была бы там чертовски нужна, если бы нормально работала.


Пусть лучше отдельно где-нибудь сидит, а то ораклу никакой памяти не хватит.

Сообщение было отредактировано: 25 июн 20, 12:46
25 июн 20, 12:49    [22157146]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
Она там неэффективно работала по причине хронической нехватки памяти
(никакой админ не даст ей больше нескольких гигабайт) и по причине морального
устаревания language/jvm. Второй пункт превращает нормального Java-разработчика
в какого-то странного ретрограда. И эффективность взаимодействия с SQL-машиной
под большим вопросом. Те типы данных которые использует Oracle (NUMERIC/VARCHAR2)
на бинарном уровне не совместимы с long, java.lang.String. Тоесть это две совершенно
чужеродные технологии и чтоб они могли эффективно машраллить-сериализовывать
эти структуры через разделяюмую память - надо было об это думать заранее.
27 июн 20, 12:46    [22158179]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
PL/SQL ещё на два десятилетия древнее и ретрограднее. А что касается причин неэффективной работы - не думаю, что мы знаем достаточно, чтобы о них говорить. Факт в том, что если бы Java внутри Oracle работала эффективно - это позволило бы хорошо решить многие задачи и в прямом смысле открыло бы новые горизонты. А вместо этого её встроили сугубо для проформы.
27 июн 20, 13:05    [22158183]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
dmdmdm
Member

Откуда: Нижний Новгород
Сообщений: 1494
В то время как максималисты рассуждают про "проформу" и "моральное устаревание", остальные тупо пользуются жавой .
27 июн 20, 13:37    [22158199]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer,

Вы какой-то технический смысл можете в свои слова встроить?
Какие именно "многие задачи" вы хотели бы на ней решать, и какова та контраформа, которая привела бы вас в восторг.

Меня пока много больше печалит способ, которым были подрублены корни Ada в PL/SQL,
полученные "упрощения" и "удобства" на стороне клиентского PL/SQL по сути отрубают возможности работы
с обобщенными типами данных. В то же время, разглядывание системных пакетов, говорит, что на стороне ядра у PL/SQL открыты
дополнительные возможности, недоступные для клиентского PL/SQL.

В общем, меня не печалит как именно Java встроена в сервер.
Больше печалит отсутствие единства PL/SQL для писателя клиентского кода и системных пакетов.
И я бы прыгал от радости и хлопал в ладоши, если бы PL/SQL явно был бы просто специфическим форком Ada,
и развивался примерно параллельно языку прародителю, предоставляя примерно эквивалентные возможности.

Кажется, после появления типов-объектов в 8-ке как словарных сущностей, такого рода надежда превратилась в "просто фантастику".

((;
27 июн 20, 13:44    [22158203]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
booby
Какие именно "многие задачи" вы хотели бы на ней решать

Этот вопрос сводится к вопросу "какие задачи плохо решает PL/SQL". А таковых довольно много.

Наиболее конкретно я ругался на недостатки встроенной явы в одной конторе, где стояла задача оптимизации местного творения. Вкратце, там софт работал следующим образом: дикая прорва сырых данных грузилась в базу, позаписно обрабатывалась сложной бизнес-логикой и удалялась, а результаты записывались и уже использовались в дальнейшем процессе. Сырые данные клались в персистентные таблицы, так как из-за некоторых особенностей бизнес-процесса требовался доступ к ним из разных сессий. Вынести обработку на уровень до базы было бы правильно, но на момент моего прихода практически нереально (по сути это было бы написать с нуля другую систему, в которой повторить все навороты бизнес-логики, накопившиеся за кучу лет, причём так, чтобы сотня клиентов смогли прозрачно и незаметно переехать на новую версию). В результате такой архитектуры база в буквальном смысле слова насиловала ввод-вывод, плодила неимоверные объёмы журналов в этом месте было охрененное бутылочное горлышко.

Очевидным путём оптимизации было бы перенести хранение этих временных сырых данных в оперативку. Да, конечно, гигабайт-другой на них бы ушёл, но также ушла бы нагрузка с PGA, буферного кэша итп, и общий прирост производительности был бы просто офигенным. Мне удалось довольно просто внедрить в существующую систему API для доступа к временным данным - уровня "дай мне запись по id", "поменяй временные данные по id" - а вот дальше начались танцы. Если коротко, в рамках одной сессии всё великолепно работало, но как только требовался обмен данными между сессиями - любая реализация уходила в унитаз. Оказывалось, что мать-мать-мать вставить в таблицу в одной сессии и прочитать из другой - кроет любое java-взаимодействие как слон комара. И не потому, что java такая плохая - вне базы тот же код отлично и быстро работал - а потому что мать-мать-мать так работает java внутри базы. И попытки из базы стучаться к движку снаружи базы - тоже мать-мать-мать тормозят как будто их делают сотрудники Почты России. И это я уже не говорю о том, что кучу кода приходилось писать самому вместо того, чтобы пользоваться доступными готовыми решениями, просто потому, что уже хрен отыщешь актуальные готовые решения, которые компилировались бы в java 4.

Ну а где ещё пригодилась бы хорошо работающая Java... во-первых, везде, где хочется уровня обобщения и абстракции большего, чем позволяет PL/SQL. Надеюсь, не обязательно перечислять миллион таких мест. Во-вторых же - можно было бы подумать над выполнением внутри базы многого из того, чем яваголовые грузят application server. Фактически ушли бы многие причины, подталкивающие к выбору трёхзвенной архитектуры.
27 июн 20, 17:44    [22158286]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
Даже просто размер строки VARCHAR2 в 32 килобайта - это уже ограничение для современного бизнеса.
Оно - то понятно что в нормализованой модели редко такое бывает. Но данные - бывает часто заходят
в полу-сыром виде. И это не только XML/Json. И похитрее форматы бывают. Теже офисные документы.

Да конечно можно вынести это в application. Но если тема топика - улучшение PL-машины то у нас уже
есть поинты куда ее хотелось-бы улучшать. Языковые возможности. Ada. Или может лучше Oberon?

И просто тот сценарий который описал softwarer.

Ну и мультипоточка. Сетевые сокеты. I/O.
27 июн 20, 18:04    [22158292]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
semirax
Member

Откуда:
Сообщений: 451
Arists,

Похвально, что вы озаботились увеличением эффективности кода. Я тоже в свое время об этом думал и пришел к следующим советам, которые могут оказаться полезными.

1) расстановка приоритетов.
а) в первую очередь код должен работать правильно в смысле логики, во вторую очередь быстро.
б) если удалось сделать правильно работающий код, то прежде чем увлекаться оптимизацией, надо озаботиться покрытием кода юнит-тестами. Без юнит-тестов код очень хрупок и любая агрессивная оптимизация его может сломать в непредсказуемом месте.

2) как правило, лучший способ оптимизации - это перепродумывание всей логики приложения с нуля (структуры таблиц, ER-модели), а не допиливание отдельных селектов при помощи хинтов. Высокоуровневая оптимизация выручает в гораздо большем числе случаев, чем низкоуровневая, и начинать надо с нее.

3) как правило, красиво написанный код оказывается надежнее некрасивого. Причина, возможно, в том, что красота добавляет коду прозрачности, а в понятном коде проще искать баги.

4) как правило, лучше иметь стандарт кодирования и жестко его придерживаться. Стандарт может быть любым, но он должен быть.
Мои рекомендации стандартные и идут еще от Кайта
а) отличать ключевые слова и названия системных пакетов от всего остального - например, все системное всегда писать с большой буквы (SELECT)
б) отличать названия локальных, глобальных переменных и параметров функций по префиксу ("g" - глобальная переменная пакета, "a" - параметр процедуры/функции, "l" - локальная переменная).
в) договориться об отступах при переходе к вложенным блокам, например делать +2 пробела при переходе к следующему уровню вложенности
д) договориться везде в названиях типов использовать не явное указание типа в духе VARCHAR2(100), а ссылаться на таблицу вида имя_таблицы.поле%TYPE. Когда таблиц становится 200-300, очень помогает.

Сообщение было отредактировано: 27 июн 20, 19:34
27 июн 20, 19:31    [22158321]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer,

Чтобы содержательно комментировать тот сыр-бор, который вы описали, надо, конечно,
и видеть весь контекст, и понимать, на какое историческое время он накладывается.

Ваше описание я понял так: грузится "большой набор сырых данных", который затем последовательно или параллельно
обрабатывается одновременно в нескольких сеансах, в условиях общей высокой нагрузки на систему, превышающий ее возможности, в первую очередь, по вводу-выводу.
В былые времена, для описываемых вами ситуаций, рекомендовали приделывать фронт с какой-нибудь Berkeley DB,
в современных версиях для чего-то похожего можно прилаживать Inmemory Tables

С точки зрения "былых времен" можно с разных сторон заходить на решение проблемы, из которых на первое место,
вообще до всего остального, я бы категорически, и преодолевая истерики по части "и так медленно работает", поставил бы
уменьшение степени параллельности обработки.
До разборок сорта - ява ли она, где и каким боком хороша, или как добавить память в сервер.

Касательно слепящей силы явы сказать можно следующее:
Скорее всего, почти наверно, вы ухудшили ситуацию, ввязав в это дело яву, но винить её я не стал бы....
Так, если система задохлась от log file sync, например, - ява никаким боком, ни при какой серверной реализации,
помочь не сможет, просто потому, что свою долю процессорного времени не получит.
К таким историям сначала должны подключаться администраторы, просто потому что "плохая программа"
уже есть и как-то плохо работает.

Что касается "вынести работу в память" - сам по себе заход может оказаться и разумным и правильным,
при правильном подходе, реализации и удобном для этого случае.
Но прежде всего надо понимать, что с точки зрения вызова в текущем сеансе - любой код pl/sql - однопоточный.
Все возможности по взаимодействию сеансов лежат либо постоянных таблицах, либо очередях, либо в dbms_pipe + dbms_alert.
А вся "многопоточка" - в джобах. В общем, все.
Если путем работы с памятью удается "кешированием" решить проблемы ввода-вывода, да еще и сгруппировать запись, хотя бы с forall - система может задышать и без администратора.

Пусть теперь, внезапно, сеансу потребовалась ява.
Тогда в сеанс будут загружена персональная, имени этого сеанса ява-машина,
которой будет предоставлен один процессор.
Для загруженных многопользовательских систем с дефицитом оперативной памяти - это слишком очевидное зло, чтобы вообще начинать о нем мечтать - этих ява-машин загруженных будет столько, сколько открыто сеансов.

Единственное оправдание, это когда в стандартное библиотеках у явы есть некий внезапно понадобившийся функционал,
повторить который без помощника - две недели, с помощником - полгода, а написать оболочку к нему и вызов из pl/sql - пять минут.
Такого рода истории почти всегда и почти автоматически решаются однозначно, но процент таких "потребностей",
до xml-безумия, был, с моей точки зрения, ничтожно мал.

2 mayton
"многопоточка" и однопоточное исполнение pl/sql в сеансе - это "интересно". :))

"лучше Oberon" - а) его нет, это "история", причем промышленно не состоявшаяся.

Ada не просто исторический прототип PL/SQL сорта взяли плохую аду, улучшили/облегчили и получился хороший PL/SQL.
Ada жива, развивается, исторически была первым примером подхода к обобщенному программированию,
и первой попытки реализации "стандартной библиотеки",
а с 2012 года, является первым примером языка с работающими контрактами.
Атрибуты типа у неё были всегда, задолго до мучительного изобретения слов сорта traits и некоторых следом новых.
Просто - атрибут типа. Он у типа есть. И новые слова - не нужны.
Это печалит, но я уже не на столько молод, чтобы этому печалиться.

Сообщение было отредактировано: 27 июн 20, 23:27
27 июн 20, 23:28    [22158433]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
booby

2 mayton
"многопоточка" и однопоточное исполнение pl/sql в сеансе - это "интересно". :))

Если вы мучались с использовали dbms_job/scheduler то вы должны меня понять.

Ada не просто исторический прототип PL/SQL сорта взяли плохую аду, улучшили/облегчили и получился хороший PL/SQL.
Ada жива, развивается, исторически была первым примером подхода к обобщенному программированию,
и первой попытки реализации "стандартной библиотеки",
а с 2012 года, является первым примером языка с работающими контрактами.
Атрибуты типа у неё были всегда, задолго до мучительного изобретения слов сорта traits и некоторых следом новых.
Просто - атрибут типа. Он у типа есть. И новые слова - не нужны.

Ладно к чорту Оберон. И не сильно он мне был нужен.

А не просвятите, где сейчас применяется Ада? Кроме общеобразовательных сфер конешно.
Просто для меня это экзотика.
27 июн 20, 23:37    [22158440]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
mayton

А не просвятите, где сейчас применяется Ада? Кроме общеобразовательных сфер конешно.
Просто для меня это экзотика.

В штатах - большинство авионики, и кое-какой космос.
В Европе - железные дороги, главным образом.
В общем, почти целиком ушла в программирование контроллеров и прочий околопромышленный софт.
Кто-то, французы, кажется, какой-то софт для банкоматов на ней пишут.
Ада-люди, кроме США, живут во Франции, Германии, Голландии. Вроде в Англии каки-то сумасшедши тоже есть.

У нас почти загибла.
Когда-то летала на самолетах Бериева.
Не знаю, сейчас на БЕ-200 выкорчевали её или всё еще летает...
28 июн 20, 00:07    [22158444]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
booby
В былые времена, для описываемых вами ситуаций, рекомендовали приделывать фронт с какой-нибудь Berkeley DB, в современных версиях для чего-то похожего можно прилаживать Inmemory Tables

Для того, чтобы приделать фронт, надо полностью перенести в него офигенную тучу бизнес-логики. Это по сути проект "разработайте мне такую же систему заново и чтобы во всех тонкостях была совместима со старой". А inmemory в десятом оракле как-то не особо.

booby
поставил бы уменьшение степени параллельности обработки.

С этим проблем не было. Процессоры по большому счёту простаивали. Как я уже сказал, бутылочным горлышком становился объём дискового ввода-вывода. Для простоты картины можно считать, что записи сначала делался insert, потом в зависимости от параметров, настроек итп. сколько-то раз делался update, и в конце - delete. То, с какой скоростью сервер был способен писать логи этих операций, по сути и определяло нагрузку, с которой система могла справиться. С какой степенью параллельности делались эти апдейты - дело десятое. Ну то есть её конечно тюнили ещё до меня, выскребая результат получше, но таким образом итоговый результат менялся на проценты, а интересовали разы.

booby
Скорее всего, почти наверно, вы ухудшили ситуацию, ввязав в это дело яву, но винить её я не стал бы....

Я и не виню яву. Как бы объяснить на пальцах.... Ну вот смотрите, есть api с операциями типа "сохранить кортеж по id" и "прочитать кортеж по id". При вызове его на реальной системе с реализацией через оракловые таблицы оно работает со скоростью тысяча попугаев в секунду. При этом 90% нагрузки на сервер - это работа этой реализации. Я пишу на яве модуль, реализующий то же api, которой на том же железе отрабатывает ту же тестовую последовательность вызовов со скоростью, например, восемьдесят тысяч попугаев в секунду. После этого я подгружаю этот модуль в оракловую базу, заменяю им реализацию через таблицы - и получаю скорость двадцать пять попугаев в секунду. Матерюсь, выношу этот модуль в отдельное приложение, крутящееся рядом с базой, делаю из базы доступ к этому приложению - и всякими финтифлюшками ухитряюсь в итоге добиться скорости аж двести попугаев в секунду, причём само приложение занимает ноль процентов, а сто процентов уходят на доступ к нему из оракла. Не буду описывать дальнейшие эксперименты, не в них суть. В этом месте я делаю вывод, что ява-машина включена в СУБД, мягко говоря, через задницу.

booby
К таким историям сначала должны подключаться администраторы

Да подключались они, только толку....

booby
Но прежде всего надо понимать, что с точки зрения вызова в текущем сеансе - любой код pl/sql - однопоточный. Все возможности по взаимодействию сеансов лежат либо постоянных таблицах, либо очередях, либо в dbms_pipe + dbms_alert. А вся "многопоточка" - в джобах.

Угу. Именно так та система и была реализована.

booby
В общем, все. Если путем работы с памятью удается "кешированием" решить проблемы ввода-вывода

Нет, не удавалось. Там просто требовалось выполнить N dml-ей, каждый из которых писал в среднем K байт в redo. Когда N*K начинал превышать возможности дисковой подсистемы - серверу предсказуемо плохело, а клиенты без восторга относились к идее уменьшать N методом "купить новый сервер и перенести половину нагрузки туда".

booby
Пусть теперь, внезапно, сеансу потребовалась ява. Тогда в сеанс будут загружена персональная, имени этого сеанса ява-машина, которой будет предоставлен один процессор.

О, да. Это одна из тех выдающихся глупостей реализации, про которые я сначала даже не подозревал, что так могли сделать. Мало того, эта ява-машина ещё и практически однопоточная, и ни хрена не имеет адекватных механизмов общения с ява-машинами других сессий в той же СУБД.

booby
Для загруженных многопользовательских систем с дефицитом оперативной памяти - это слишком очевидное зло

Откуда вы выдумали "загруженную многопользовательскую систему с дефицитом оперативной памяти"? Чем она была загружена - я уже не раз повторил. Многопользовательскую.... ну сколько сконфигурили сессий, столько и пользовательскую. Дефицита памяти там не было. И дефицита процессоров тоже не было. Сервер стоял и скучал, пока надрывался ввод-вывод, который забивали бешеным количеством байт от бешеного количества update-ов временных данных, которым через долю секунды делали delete и которым нахрен не был нужен никакой acid, никакое восстановление итп.
28 июн 20, 00:35    [22158461]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer,

вы пропустили критический момент - если сервер гибнет от log file sync, лечить его явой бесполезно.

что касается глупости, здесь надо сказать, что вообще все соображения связанные
с надёжностью и безопасностью, безусловно, являются глупостями.

Очевидно же, глупо рассчитывать на то, что клиентский код сможет завалить сеанс.
Ясно, что этого не будет никогда.
Поэтому совершенно безопасно запускать одну ява-машину на всех.
Раз никакой сеанс не может завалиться, то нет и причин для падения одной, общей на всех ява-машины.
28 июн 20, 01:39    [22158492]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
booby,

если код завалил ява-машину, её можно просто перезапустить и через полсекунды продолжить обслуживать запросы. Можно дать возможность конфигурировать и выделять, что безопасно, а что совать в песочницу. Можно сделать уйму грамотных решений. Но раз доминирует желание пофлеймить, лично я пойду спать, что и Вам советую.
28 июн 20, 01:44    [22158494]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer
booby,

если код завалил ява-машину, её можно просто перезапустить и через полсекунды продолжить обслуживать запросы.


вы пропустили слово новые
Действительно, кому нужны чужие, других сеансов, старые, не завершившие работу запросы,
раз уж они завалились вместе с завалившейся ява-машиной.
Тут и флеймить не о чем.
28 июн 20, 02:01    [22158498]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
booby
softwarer,

вы пропустили критический момент - если сервер гибнет от log file sync, лечить его явой бесполезно.

Если приложение уже так написано и так работает - то улучшать его в рамках такой
парадигмы наверное бесполезно.

Может имеет смысл посмотреть в сторону ослабления ACID.
28 июн 20, 11:52    [22158552]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
mayton
booby
вы пропустили критический момент - если сервер гибнет от log file sync, лечить его явой бесполезно.

Если приложение уже так написано и так работает - то улучшать его в рамках такой
парадигмы наверное бесполезно.

Просто коллега выступил в духе анекдота "если бы у рыб была шерсть, в ней водились бы блохи" - не о том, о чём я написал, а о том, с чем сталкивался.
28 июн 20, 11:58    [22158553]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
mayton,
Это уже не технический разговор.
softwarer точно "знает", что он не просто всё "сделал правильно", а именно решил проблему.
И ему до лампады, в чём она состояла.
А вот ява при этом, несомненно, встроена в сервер БД "неправильно".

В продолжении такого разговора смысла ноль.

А какой-то набор в подобных ситуациях как быстрых решений со стороны
администрирования/общего управления работы сервером, так и со стороны малой корректировки кода,
не требующей его немедленного революционного переписывания обычно есть.

В "сложных случаях" такого сорта тема периодически оказывается "самовоспроизводящейся".
И как с этим жить - вообще далеко за возможностями разумных ожиданий о том, как одному разработчику жить рядом с другим.

Никому ничего нельзя объяснить, или, тем более, хоть как-то хоть о чём-нибудь договориться.
Это вообще всё, что следует знать о жизни вообще, и о программировании в частности.
28 июн 20, 23:43    [22158729]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
В данном топике я просто хотел согласиться с softwarer и добавить своё мнение о том что
Java в Oracle просто "примотана скотчем сбоку". И если-бы я влиял на эти процессы - то изначально
отказался бы от этой затеи а просто развивал бы сам PL/SQL и добавлял-бы в него языковые
и библиотечные возможности которые сейчас делаются только через Server Side Oracle JVM.
29 июн 20, 00:05    [22158738]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
mayton
И если-бы я влиял на эти процессы - то изначально отказался бы от этой затеи а просто развивал бы сам PL/SQL и добавлял-бы в него языковые и библиотечные возможности которые сейчас делаются только через Server Side Oracle JVM.

Не уверен, что это хороший путь. Оракл много лет занимался тем, что рожал монстровые языки и подходы, от Pro*C до Oracle Forms. Развить PL/SQL до уровня, кроющего яву... тут, имхо, есть два основных варианта исхода. Вариант первый: получится очередной жуткий монстр. Примерно как те ООП-шные возможности, которые уже внедрены в язык. Вариант второй: получится хороший, даже замечательный язык. Ни с чем не совместимый, практически без библиотек и практически без поддержки со стороны инструментальных средств. Думаете, оправдано будет сидеть и писать на нём очередные реализации XML парсеров или библиотек работы с изображениями?

В общем, думаю, что перенести достоинства PL/SQL в яву легче, чем перенести достоинства явы в PL/SQL. И раз уж Оракл обзавёлся такой собственностью как java - было бы логично использовать её по полной программе.
29 июн 20, 01:42    [22158744]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
xtender
Member

Откуда: Мск
Сообщений: 5491
https://www.oracle.com/technetwork/database/multilingual-engine/overview/index.html
Уже есть MLE на GraalVM, сам я не тестировал, но все пишут, что он крайне шустрый
29 июн 20, 03:27    [22158747]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Elic
Member [заблокирован]

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 29861
https://www.oracle.com/technetwork/database/multilingual-engine/overview/index.html
Уже есть MLE на GraalVM, сам я не тестировал, но все пишут, что он крайне шустрый
Oracle - коммерческая структура, чем больше юзеров подсядет на недо-бд-языки в нём - тем больше его профит. От лицензий.

P.S. Плакающиеся от недо-явы, если вам охрненительно оптимизированный при правильном использовании PL/SQL не подходит, то вам нужна принципиально другая файло-помойка-БД.
29 июн 20, 07:37    [22158775]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 2478
softwarer
Для простоты картины можно считать, что записи сначала делался insert, потом в зависимости от параметров, настроек итп. сколько-то раз делался update, и в конце - delete. То, с какой скоростью сервер был способен писать логи этих операций, по сути и определяло нагрузку, с которой система могла справиться.


Когда-то хотел таблицы (тмр) для которых не генерилось бы ни undo ни redo (да, без возможности rollback)

зы
Слышал что в новых версиях появились еще какие-то тмп таблицы, но пока руки не доходят

.....
stax
30 июн 20, 10:27    [22159482]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
Stax

Когда-то хотел таблицы (тмр) для которых не генерилось бы ни undo ни redo (да, без возможности rollback)

Я тоже об этом думал.

По сути аналог PLSQL-коллекций типа TABLE OF <> INDEX BY <> , но с возможностью бегать по ней курсором.
30 июн 20, 10:50    [22159496]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18069
mayton

По сути аналог PLSQL-коллекций типа TABLE OF <> INDEX BY <> , но с возможностью бегать по ней курсором.

Возникло несколько вопросов по Вашему замечанию:
- какие именно затруднения Вы встречаете при обработке коллекций PL/SQL?
- что мешает бегать по ним курсором?
- чем, в конце концов, не угодили стандартные GTT?

...Stax говорил о nologging persistent, которые можно было бы довольно специфически использовать - к примеру, для организации межпроцессного взаимодействия и прочих подобных пакостях, которые в принципе не требуют восстановления => можно не тратиться на redo...
30 июн 20, 11:31    [22159523]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
У меня - нет затруднений. Это были мысли из серии - "неплохо было бы... "
30 июн 20, 11:37    [22159532]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 2478
mayton,

типа фоксовская дбф-ка, без редо/ундо (без логирования/восстановления), тмп/можно и не тмр

отдельный тип
create norecovery [temporary] table xxxx ...
.....
stax
30 июн 20, 11:39    [22159537]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
Ближе TimesTen. Где нету слоя db_blocks. Есть просто логика хеш-таблиц.
30 июн 20, 11:47    [22159548]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
andrey_anonymous,

им нужны постоянные таблицы для временного мусора, который виден между сеансами без нагрузки на redo-log.

При этом сконфигурировать системные буфера и местоположение логов админы не способны,
а писатели не знают ни про COMMIT WORK WRITE BATCH NOWAIT,
ни сгруппировать работу, так, чтобы уменьшить объем редо-логов не могут.

Здесь без явы, которая, как оказывается, ещё и приделана криво, вообще не жисть.
30 июн 20, 12:22    [22159580]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62610
Блог
booby
а писатели не знают ни про COMMIT WORK WRITE BATCH NOWAIT

Кто про что, а вшивый про баню. И ведь ещё двадцать раз напишет - и сам поверит, что так всё и было, он своими глазами видел
30 июн 20, 12:32    [22159592]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 2478
booby,

WRITE BATCH NOWAIT не пользовал

правда иногда ляпал по привычке WORK

да и счас туманно представляю как ето уменьшит редо/ундо,
я же хотел чтоб для некоторых типов "рабочих" таблиц их вообще не было

.....
stax
30 июн 20, 12:39    [22159601]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18069
Stax
да и счас туманно представляю как ето уменьшит редо/ундо

Если обычная таблица в nologging, операции с ней идут в batch-mode и на базе не включен force logging - то объем redo таки уменьшится :)
30 июн 20, 12:59    [22159618]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
Stax,

в ответ на ремарку об уменьшении степени параллельности был дан развернутый ответ,
смысл которого сводится к тому, что уменьшать нечего - памяти "хватает", процессоров "достаточно", но все они одновременно стоят

Я знаю только одну активность сервера, которая блокирует все процессы одновременно,
в ожидании своего завершения.
Это как раз сброс редо-логов. В их случае проблема приезжала от update.

Вместо того, что сначала уменьшить степень параллельности или разобраться с
конфигурацией, они "избавились" от проблемы способом, сопровождаемость и развитие
жизненного цикла которого под большим вопросом.

Последнее слово в команде - NOWAIT, призвано заставить выполняться commit в асинхронном режиме для конкретного процесса.
Обычно само по себе это меняет режим работы с logbuffers, и не только сеанс-инициатор не ждет окончания коммита, но и влияние "слишком быстрых обновлений" на соседние сеансы может уменьшаться примерно на порядок в тяжелых случаях, даже без снятия logging с таблицы.

То есть, если ты обрабатываешь явно мусор, потеря которого при крахе системы не имеет
значения, потому что всё равно все нажитое непосильным трудом будет поставлено на
повторную обработку, то NOWAIT - это как раз то самое "ослабление требований ACID",
о котором размышлял mayton, и которое в таких случаях вполне к месту.

PS
С конфигурацией, конечно, могут быть проблемы.
Админ может и с глузду съехать, сказав - начальник, баксов давай на диск для логов
и еще на отдельный контроллер к ним.
А время разработчика "на яве" - всегда бесплатно.
Он и так в штате, зарплата все равно платится и, что бы он ни наделал,
это не нарушит бюджетных устоев компании.
30 июн 20, 14:17    [22159686]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 2478
booby,

об NOWAIT знал (у меня не было "долгих" commit-ов, и не пользовал, да и боялся навредить ДБА),
но то что NOWAIT уменьшает обьем логирования я не знал

.....
stax
30 июн 20, 15:02    [22159716]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
Stax,

не столько объем, сколько режим работы подсистемы, это не панацея само по по себе, а штрих к прочему.
Характер и время общего "замирания" меняется.
Система из состояния - "стоит и ничего не делает", может как-то начать продыхиваться, если
других средств под рукой нет.
30 июн 20, 15:11    [22159723]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
Stax,

это проблема не " слишком долгих", а "слишком частых" коммитов,
при , одновременно, полном наплевательстве на конфигурацию.
30 июн 20, 15:13    [22159726]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47659
Хороший коммит - редкий коммит.
30 июн 20, 15:48    [22159761]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 2478
mayton
Хороший коммит - редкий коммит.

у меня на 99% зависело от прикладной транзакции

.....
stax
30 июн 20, 15:51    [22159766]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Кобанчег
Member

Откуда: Рахів
Сообщений: 768
softwarer
Если коротко, в рамках одной сессии всё великолепно работало, но как только требовался обмен данными между сессиями - любая реализация уходила в унитаз. Оказывалось, что мать-мать-мать вставить в таблицу в одной сессии и прочитать из другой - кроет любое java-взаимодействие как слон комара. И не потому, что java такая плохая - вне базы тот же код отлично и быстро работал - а потому что мать-мать-мать так работает java внутри базы. И попытки из базы стучаться к движку снаружи базы - тоже мать-мать-мать тормозят как будто их делают сотрудники Почты России.
Проблема в том, что не удалось организовать взаимодействие через некую раздяляемую область памяти для JVMs запущенных из базы?

Понятно, что архитектуру перелопачивать не всегда возможно, но для параллельной обработки для любителей java есть как минимум следующие средства
1. parallel pipelined реализованные на java (тут SQL движок будет координировать работу)
2. рулить параллельностью средствами java (тут JVM выполяет роль координатора)

Так что там про новые горизонты? Java в базе плоха ибо c трудом позволяла решать проблему на 10g которая высосана из пальца?

softwarer
И это я уже не говорю о том, что кучу кода приходилось писать самому вместо того, чтобы пользоваться доступными готовыми решениями, просто потому, что уже хрен отыщешь актуальные готовые решения, которые компилировались бы в java 4.
java 4 была в Оракл 10g. Который был выпущен 17 (!) лет назад.
Начиная с 12.2 уже версия 8. Если какой библиотеки не хватает - никто не запрещает её в базу загрузить.
Более того, есть языки работающие на JVM и которые более приспособлены для параллельных вычислений - Scala, Closure.
На них тоже элементарно писать хранимки, только ясное дело что надо грузить в базу уже скомпилированные class/jar файлы а не исходники (это только для Java).
2 июл 20, 16:22    [22161034]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Oracle Ответить