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

Откуда: 127.0.0.1
Сообщений: 62522
Блог
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
Сообщений: 62522
Блог
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
Сообщений: 47628
booby
softwarer,

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

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

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

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

Откуда: 127.0.0.1
Сообщений: 62522
Блог
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

Откуда: Мск
Сообщений: 5478
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
Сообщений: 2468
softwarer
Для простоты картины можно считать, что записи сначала делался insert, потом в зависимости от параметров, настроек итп. сколько-то раз делался update, и в конце - delete. То, с какой скоростью сервер был способен писать логи этих операций, по сути и определяло нагрузку, с которой система могла справиться.


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

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

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

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

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

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

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

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

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

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

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

Откуда: loopback
Сообщений: 47628
Ближе 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
Сообщений: 62522
Блог
booby
а писатели не знают ни про COMMIT WORK WRITE BATCH NOWAIT

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

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

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

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

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

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

Откуда: Москва
Сообщений: 18065
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
Сообщений: 2468
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить