Базы данных Oracle - статьи
Лучшие практические методы
Тесты (описаны в приложении к этой статье) показывают, что надлежащая установка значения параметра cursor_sharing позволяет повысить производительность приложений, которые были написаны без использования переменных связывания. В частности, время ответа в приложениях с часто повторяющимися операторами SQL, которые отличаются друг от друга только литералами, может быть чрезвычайно большим. Кроме указанного повышения производительности, использование этого параметра также позволяет уменьшить объем потребляемой памяти, так как разделяется большее количество операторов SQL. Однако поскольку по-прежнему выполняется частичный разбор, использование приложений без переменных связывания может привести к проблемам масштабируемости, хотя и на более высоких уровнях пропускной способности.
Кроме того, тесты показывают, что надлежащая установка значения параметра session_cached_cursors может привести к некоторому улучшению масштабируемости некоторых типов приложений, в частности тех, где используются переменные связывания, но для каждого оператора SQL будут выполняться открытие и закрытие курсора или частичный разбор. Надлежащее значение этого параметра обычно находится между количеством часто выполняемых в приложении операторов SQL и значением параметра инициализации экземпляра open_cursors.
Для хорошо спроектированных приложений (многократное выполнение разобранных операторов SQL) установка параметра cursor_space_for_time = true может привести к некоторому улучшению масштабируемости за счет потребления дополнительной памяти.
Параметры инициализации cursor_sharing и session_cached_cursors позволяют разработчикам приложений немного "смягчить" несоблюдение руководящих принципов надлежащей разработки приложений. Однако чтобы полностью обеспечить масштабируемость и производительность системы баз данных Oracle, приложения следует проектировать в соответствии с руководящими принципами корпорации Oracle.
В процессе программирования приложений следует соблюдать следующие общие рекомендации:
операторы SQL, многократно выполняемые в одном и том же модуле приложения, следует связывать с конкретными курсорами, которые открываются один раз: их операторы SQL с переменными связывания разбираются один раз и выполняются многократно. Такой способ обеспечивает возможно лучшие время ответа и масштабируемость. Этого можно добиться, используя явные курсоры в программах Oracle Precompiler и надлежащим образом используя описатели операторов (statement handles) в программах Oracle Call Interface. Программы Oracle Precompiler, использующие неявные курсоры, следует запускать с параметрами HOLD_CURSOR=YES, RELEASE_CURSOR=NO для конкретных операторов SQL или с общим параметром MAXOPENCURSORS, значение которого должно быть достаточно высоким для сохранения открытыми всех часто используемых курсоров; значение этого параметра, устанавливаемое по умолчанию и равное 10, обычно слишком мало. Этот подход также используется в программах, написанных на PL/SQL, и при использовании курсоров в циклах и декларации курсоров в статическом SQL;
операторы SQL, многократно выполняемые в разных модулях приложения, для которых нельзя применить описанный выше метод, следует выполнять с использованием переменных связывания. Если это невозможно, или если в уже написанном приложении необходимо воспользоваться преимуществами использования переменных связывания, можно установить в параметре cursor_sharing значения force или similar. Однако см. ниже замечания по приложениям систем поддержки принятия решений (decision support type applications);
в общем, следует избегать частого частичного разбора операторов SQL или открытия и закрытия курсоров. Если в приложениях это все-таки используется, то некоторого улучшения масштабируемости можно добиться, установив надлежащее значение параметра session_cached_cursors, но установка этого параметра не должна подменять корректного программирования приложений;
не следует совершенно отказываться от использования в приложениях переменных связывания, полностью полагаясь на использование параметра cursor_sharing. Главное достоинство этого параметра заключается в повышении производительности существующих приложений, в которых переменные связывания не используются, что помогает избегать дорогостоящего полного разбора. Заметим, проблемы масштабируемости при обработке SQL возникают также из-за выполнения частичного разбора; использование этого параметра не помогает избавиться от частичного разбора. Заметим также, что никаких преимуществ от использования этого параметра не получают приложения, в которых фактически отсутствует многократное выполнение операторов SQL, отличающихся только литералами, а также приложения, не испытывающие реальных проблем с выполнением разбора;
как исключение операторы SQL, в частности, сложные операторы SQL, которые редко выполняются чаще одного раза, должны разбираться с использованием литералов и без использования переменных связывания, что позволит оптимизатору воспользоваться всеми преимуществами доступных статистик. Более подробно об этом см. в разделе "Особые ситуации".
Примечательно, что кроме повышения производительности, использование параметра cursor_sharing позволяет обеспечить реальное разделение операторов SQL, которые в противном случае были бы различными из-за различий в литералах (это также влияет на потребление памяти).
И еще следует упомянуть, что для некоторых приложений или некоторых частей приложений, использующих литералы, не желателен запуск с установленными значениями параметра cursor_sharing, если они отличаются от значения по умолчанию. В частности, это справедливо, если в вашем приложении используются литералы, которые не изменяются между вызовами. Примером такого оператора SQL может быть оператор со списком литералов в предикате (IN-list), типа: select * from elements where status in (1,4)
Здесь при каждом вызове оператора будут использоваться фактически одни и те же значения литералов: 1 и 4.
