Результаты

В контексте данной статьи приложения, которые используют сходные (similar) операторы SQL (то есть операторы SQL, отличающиеся только фактическими значениями литералов), можно разделить на три категории:

Приложения, в которых не используются переменные связывания. Такой стиль программирования наблюдается часто, когда разработчики приложений не осведомлены о важности уменьшения количества разборов, или когда приложения переносятся из других СУБД.

2a.

Приложения, выполняющие все шаги для каждого отдельного оператора SQL: открытие курсора, разбор с переменными связывания, выполнение (и выборка для запросов) и закрытие курсора. Это – поведение Oracle Forms при входе и выходе из блоков, а также в собственном динамическом SQL (native dynamic SQL) языка PL/SQL. Преимущества использования переменных связывания при таком подходе не очевидны программистам, работающим с интерфейсом вызовов Oracle (Oracle Call Interface, OCI) или прекомпиляторами Oracle (Oracle Precompilers), поэтому в этой среде переменные связывания встречаются редко.

2b.

Приложения, в которых для каждого оператора SQL один раз открывается курсор, а затем многократно выполняются следующие шаги: разбор с переменными связывания, выполнение (и выборка для запросов). Этот тип приложений часто наблюдается, когда разработчики приложений используют Oracle Precompilers с опциями HOLD_CURSOR=NO (не удерживать курсор) и RELEASE_CURSOR=NO (не освобождать курсор), которые устанавливаются по умолчанию, или когда используется пакет PL/SQL DBMS_SQL.

Приложения, в которых для каждого отдельного (отличного от других) оператора SQL один раз открывается курсор, выполняется разбор с переменными связывания, а затем следует многократное выполнение (и выборка для запросов). Это наиболее эффективный способ разработки приложений, многократно исполняющих одни и те же операторы SQL. Обычно наблюдается в хорошо спроектированных приложениях, разработчики которых использовали Oracle Call Interface или Oracle Precompilers. Особенно это относится к Oracle Precompilers, когда для конкретных операторов SQL используются опции HOLD_CURSOR=YES (удерживать курсор) и RELEASE_CURSOR=NO (не освобождать курсор), или используется установка общего параметра MAXOPENCURSORS (максимальное количество открытых курсоров), которая определяет поведение неявных курсоров для данной категории приложений. Этот подход также используется в программах, написанных на PL/SQL, и при использовании курсоров в циклах и явных курсоров в статическом SQL.

Категории 2a и 2b практически идентичны, так как фактическое открытие и закрытие курсоров оказывает очень малое влияние на производительность, реальные накладные расходы – на разбор.

Производительность приложений, в общих чертах можно определять по времени ответа, то есть реальному времени, затраченному на каждое выполнение оператора SQL, а также по пропускной способности или масштабируемости, то есть способности параллельно выполнять многочисленные копии приложения. Оба этих показателя производительности были измерены для различных категорий приложений с различными сценариями установки значений параметров инициализации cursor_sharing и session_cached_cursors, рассмотренных ранее. Результаты измерений по каждой из трех категорий приложений, перечисленных выше, в комбинации с параметрами инициализации сведены в показанную ниже таблицу. В приложении к этой статье приведены некоторые фактические результаты тестов, которые были специально разработаны для демонстрации поведения различных категорий приложений.

Категория приложения

Общее поведение

cursor_
sharing = force или similar

session_
cached_
cursors = достаточно высокое значение

cursor_
space_for
_time = true

1. Совершенно не используются переменные связывания.

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

Значительное сокращение времени ответа и увеличение масштаби-
руемости; хотя результаты не столь хороши, как в приложениях 2-й и 3-й категорий.

Незна-
чительное улучшение исходных данных.

Никакого влияния.

2. Разбор с переменными связывания, выполнение (и выборка) для каждого выполнения оператора SQL.

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

Никаких допол-
нительных улучшений.

Сокращается время ответа и увеличивается масштаби-
руемость, так как сервер сохраняет кешированные курсоры. Никакого влияния.

3. Однократное открытие курсора и разбор с переменными связывания, многократное выполнение (и выборка).

Самые лучшие из возможных время ответа и масштаби-
руемость.

Никаких допол-
нительных улучшений.

Никаких допол-
нительных улучшений

Допол-
нительное увеличение масштаби-
руемости.

Содержание раздела