PL/SQL Native Compilation - "разгон" выполнения хранимых процедур

Oracle Database версии 11g, помимо множества новых возможностей и улучшений, принесла еще одну замечательную технологию - PL/SQL Native Compilation.

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

Существует два варианта компиляции ваших хранимых процедур PL/SQL:
- interpreted (в результате из исходного кода процедуры получается интерпретируемый код виртуальной машины PL/SQL);
- native (в результате компиляции на выходе получается исполняемый код текущей платформы).



Понятно, что в втором случае достигается максимальная скорость выполнения хранимой процедуры, поскольку отсутсвует фаза интерпетации кода виртуальной машины PL/SQL (как в первом случае), и код напрямую выполняется на процессоре.

Возможность компиляции кода процедуры была доступна еще начиная с версии 9.2 , но она была реализована через генерацию промежуточного C-кода, с последующей его компиляцией в нативный код платформы. Это создавало массу неудобств:
- нужно лицензировать и устанавливать C-компилятор;
- после линковки объектного модуля на выходе получался большой по размеру файл разделяемой библиотеки (dll,so,sl, ...), потому-что линкер честно "запихивал" в каждый модуль runtime-библиотеку C.

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

Лично мой опыт показал, что для получения максимального выигрыша от этой технологии мне потребуется сделать редизайн и перегруппировку своего PL/SQL-кода, что было невозможно по временным и ресурсным ограничениям. Я использовал платформу Windows и компилятор Visual C. После компиляции получались dll-файлы неприличных размеров - выполняемый код "разбухал".
Вообщем: Native Compilation не пользовался успехом у разработчиков и администраторов.

Но теперь все это позади - начиная с 11-ой версии, компилятор PL/SQL может генерировать исполняемый код на "лету", - нет необходимости ставить и настраивать С-компилятор.
Все что для этого нужно: это установить параметр PLSQL_CODE_TYPE в значение NATIVE, и после этого перекомпилировать процедуры.

Какой выигрыш в скорости выполнения обеспечивает native-компиляция PL/SQL ?
Все зависит от вашего PL/SQL-кода: если в нем много логики, но мало обращения к БД (к SQL-движку), то скорость возрастает в разы! Если наоборот, весь код состоит из оператов SQL, то выигрыш конечно будет небольной, - обращения к СУБД "съедают" львиную долю времени выполнения.
В большинстве случаев код имеет смешанный характер, то есть состоит из вычислительной обработки и операторов SQL. Nаtive Compilation даже в этом случае дает существенный выигрыш в производительности. Конечно, реальный коэффициент ускорения может быть получен только после тестов на конкретном приложении.

В случае принятия решения об использовании PL/SQL Native Complilation рекомендуется целиком перекомпилировать весь PL/SQL в СУБД. В документации по PL/SQL приведена подробная инструкция как это сделать: Compiling the Entire Database for PL/SQL Native or Interpreted Compilation


Недавно в одном из проектов я попробовал эту технологию. Код приложения состоял примерно из 3 млн. строк кода PL/SQL. Код приложения хорошо структурирован и состоит из небольших процедур сгруппированных по пакетам, поэтому дополнительно я включил третий уровень оптимизации PL/SQL (параметр PLSQL_OPTIMIZE_LEVEL=3).

По результатам тестов - скорость выполнения увеличилась примерно в три раза !

Хочу поделиться некоторыми наблюдениями:
- время компиляции в Native-режиме сильно замедляется (на моем 2-хпроцессорном сервере с 2 Xeon Nehalem перекомпиляция всей СУБД заняла около 4 чаcов!), поэтому ее не рекомендуется включать на development-среде;
- возрастают требования к памяти - выполняемый код больше по объему, чем код PL/SQL VM (в моем случае процентов на 10-15, но скорее всего это из-за inline-подстановки);
- при выполнении native-скомпилированных процедур возрастает утилизация процессоров, поэтому при переходе в этом режим нужно иметь запас в CPU, на мой взгляд - минимум процентов на 20-30.

По-моему PL/SQL native compilation очень интересная возможность Oracle Database 11g - почему бы ее не использовать ?

P.S. Поделилтесь, пожалуйста, в комментариях к этому посту о своем опыте использования этой технологии.