|
Программирование >> Oracle
Глава 10 вить ее работать быстрее, не переделывая полностью заново. Именно последнее требование и делает настройку постфактум настолько сложной. Если думать о производительности на всех этапах жизненного цикла приложения, окажется, что это - наука, а не искусство. Все могут это делать, если это регламентировано. Для этого необходимо определить показатели, по которым будет проверяться производительность приложений. Необходимо снабдить код средствами контроля и отладки, чтобы можно было определить, где происходит замедление. Включение таких средств - крайне важно; сам сервер обильно снабжен такими средствами, как было показано в этой главе. Эти средства отладки можно использовать для доказательства того, что не СУБД является причиной медленной работы, а какая-то другая система. После этого, если остальной код приложения не снабжен средствами контроля и отладки, придется определять причину проблем наугад. Но и для кода, выполняемого в СУБД, средства контроля и отладки на уровне приложения весьма полезны при выявлении причины медленной работы. Да, если вы еще не запомнили: использование св1ваем1х переменн1х - крайне важно. Я встречал бессчетное количество систем, обреченных на остановку лишь потому, что разработчикам показалось удобнее использовать во всех запросах конкатенацию строк вместо подстановки переменных. Эти системы не работали. Правильное решение в данном случае - использовать связываемые переменные. Не полагайтесь на фокусы типа установки параметра CURSOR SHARING, поскольку с ними тоже связаны определенные проблемы. Стабилизация плана оптимизатора Сервер OracleSi позволяет разработчику сохранить набор подсказок серверу , описывающих, как выполнять определенные SQL-операторы в базе данных. Эта возможность называется стабилизацией плана оптимизатора (Optimizer Plan Stability) и реализуется с помощью хранимого шаблона плана выполнения запроса, аналогичного шаблону верстки книги. В этой главе мы подробно рассмотрим эту возможность, в том числе: В каких случаях при разработке приложений может понадобиться стабилизация плана оптимизатора, и какие сценарии работы должны при этом использоваться. Альтернативные варианты использования этой возможности, не предполагавшиеся разработчиками сервера. Стабилизация плана оптимизатора и управление хранимыми шаблонами планов в базе данных как с помощью операторов ЯОД, так и с помощью подпрограмм пакета OUTLN PKG. Существенные нюансы, включая чувствительность к регистру символов, проблемы с оператором ALTER SESSION, раскрытием условий OR и производительностью. Ошибки, с которыми можно столкнуться, в том числе отсутствие опций в операторе ALTER OUTLINE или наличие шаблона плана с данным именем, и способы их устранения. Для выполнения примеров в этой главе необходим сервер OracleSi Release 1 (версия S.1.5) или более новой версии. Кроме того, это должна быть редакция OracleSi Enterprise Глава 11 или Personal Edition, поскольку стабилизация плана оптимизатора в Standard Edition не поддерживается. Обзор возможностей Для выполняемого запроса или набора SQL-операторов стабилизация плана оптимизатора позволяет сохранить оптимальный набор подсказок, избавляя от необходимости задавать подсказки в приложении. Это позволяет: разработать приложение; протестировать и настроить его запросы; сохранить соответствующие хорошо настроенные планы выполнения в базе данных для использования оптимизатором в дальнейшем. Стабилизация плана оптимизатора позволяет защититься от многих изменений используемой базы данных. Существенно изменить планы выполнения запросов могут, в частности, следующие типичные изменения базы данных: повторный анализ таблицы после изменения количества данных; повторный анализ таблицы после изменения распределения данных; О повторный анализ таблицы с помощью других методов или параметров; изменение различных параметров в файле init.ora, влияющих на поведение оптимизатора, например db block bulfers; добавление индексов; обновление версии ПО Oracle. Благодаря стабилизации плана запроса, однако, можно сохранить существующие планы выполнения запросов и изолировать приложение от этих изменений. Следует отметить, что в большинстве случаев желательно, чтобы планы выполнения запросов со временем изменялись в ответ на события из приведенного выше списка. Если распределение данных по столбцу существенно изменяется, оптимизатор соответственно изменяет план выполнения запроса. Если добавлен индекс, оптимизатор выявит и использует его, если это даст преимущество. Стабилизацию плана оптимизатора можно использовать для предотвращения подобных изменений в среде, где изменения должны делаться постепенно, после тщательного тестирования. Например, прежде чем разрешать использование индекса, можно последовательно протестировать запросы, для которых он используется, чтобы убедиться, что добавление индекса не повлияет отрицательно на другие компоненты системы. То же самое справедливо и в отношении изменения параметров инициализации или обновления ПО сервера. Стабилизация плана оптимизатора реализуется с помощью подсказок. Подсказки - это не команды и не правила. Хотя механизм подсказок, лежащий в основе стабилизации плана оптимизатора, мощнее, чем в случае обычных подсказок в тексте запроса, оптимизатор может по ходу работы им и не следовать. Это - палка о двух концах. Кажется, что это - недостаток, но это - полезное свойство. Если в базе данных сделаны такие изменения, что набор подсказок неприменим (например, удален соответствую-
|
© 2006 - 2025 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки. |