Monday, March 12, 2012

Какие приложения будут успешно "взлетать" на Экзадате ?

В дополнение к моему предыдущему посту "Какие приложения будут успешно "взлетать" на Экзадате ?" .

Появился еще один критерий для отброса плохих приложений: Какую долю в Вашем приложении занимает SQL ?


Как известно, в состав СУБД Oracle входят SQL-машина и PL/SQL-машина.
SQL машина выполняет Select, Insert,Update,Delete.
PL/SQL-машина выполняет конструкции языка PL/SQL, например, циклы и условные переходы.
Есть еще Java-машина. Она выполняет java-код.

В ряде случаев не удается всю логику приложения реализовать только на SQL.
Поэтому разработчики реализуют ее в PL/SQL. Например, создают свои массивы, очереди AQ и пишут свои процедуры-функции для их обработки.

Фактически, таким образом, разработчики реализуют свою СУБД внутри Оракла.

Такие приложения плохо экзадатятся.

Во, первых, для таких приложений не работают основные фичи: smart scan, storage index.  Т.е. Экзадате попросту нечего смарт-сканить, поскольку в приложении очень мало SQL. Типичный сценарий: приложение запрашивает строку с диска, сервер хранения ее отдает целиком и дальше обработка данных происходит в PL/SQL-процедурах (= только на сервере БД ).
В качестве варианта - прикладной код выносится на отдельный сервер, который реализует обработку данных.

Во-вторых, такие приложения плохо распараллеливаются Ораклом и админом-эксплуатационщиком, потому что для запуска нескольких параллельных сессий необходимо знакомство с архитектурой приложения. Идеальное железо для такого приложения - один очень быстрый процессор. Но поскольку таких быстрых процессоров еще в природе не существует, то приходится изобретать параллельность. Поэтому для увеличения производительности разработчики создают свои структуры с помощью которых управляют количеством параллельных процессов. В результате, СУБД Оракл не может извлечь пользу из automatic DOP или установить степень параллельности на уровне объектов, потому что  процесс все равно продолжает выполняться в один поток. Иными словами, регулировать степень параллельности может только разработчик.

В третьих, таким приложениям как правило становится плохо от RAC. Для улучшения производительности надо отключить один узел, тогда приложению становится легче. 



Рекомендации:
Если Вы узнали в описанных выше симптомах свое приложение, то переносить его на Экзадату не имеет смысла. Показать результаты близкие к Экзадате сможет даже простая персоналка. Из 60 физических ядер, способных выполнять SQL такое приложение обычно задействует 12 (одну DB ноду), потому что от RAC его тошнит, и обычная Оракловая параллельность на два узла не распределяется. Smart scan отсутствует, поэтому 36 физических ядер также простаивают.
В результате сравнения с персоналкой заказчик делая разумный выбор, должен предпочесть персоналку. Идеальное железо для такого приложения - один очень быстрый процессор.

Вот пример одного приложения, которое не получит пользы от перехода на Экзадату.
В AWR-отчете Оракл показывает долю SQL и PL/SQL за отчетный период:




В общем, прежде, чем переходить на Экзадату смотрим на соотношение статстистик на продуктиве:
sql execute elapsed time, DB CPU,
PL/SQL execution elapsed time
Java execution elapsed time.

Если в Вашей системе не-SQL занимает значительную долю времени, то зачем Вам вообще нужна СУБД ?


No comments:

Post a Comment

Could not locate shrept.lst make: *** [client_sharedlib] Error 1

 Installing the quarterly database patch i got unpleasant message : " Patching component oracle.sdo, 12.2.0.1.0... Make failed to ...