В дополнение к моему предыдущему посту
"Какие приложения будут успешно "взлетать" на Экзадате ?" .
Появился еще один критерий для отброса плохих приложений: Какую долю в Вашем приложении занимает 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 занимает значительную долю времени, то зачем Вам вообще нужна СУБД ?
