Все наилучшие практики и возможности предоставляются PL/SQL в Oracle Database 11g.Вы, скажем, прочитали, что Oracle выпустил 11-ый релиз базы данных. Замечательно! Но возникает проблема - вы не предполагаете ее использование в ближайшие два года. А потому надо ли вам задумываться о новых возможностях в PL/SQL этой версии? Посмотрим на мир реально. Oracle выступил с новым релизом базы данных, и это значит, что его разработчики ужсфокусированы на этот новой релиз. Люди вроде меня начинают писать, демонстрировать и даже обучать этой новой версии. А значит, есть и другие: те, кто остается пока на более старой версии, кто надеется и молится на то, что однажды их менеджмент может быть сочтет целесообразным устранить это несоответствие. Я разделяю ваши заботы. Я думаю и хочу сказать, что именно сейчас имеет смысл изучить те возможности, которые Oracle Database 11g предложит вам и вашей компании в будущем. Причина очень проста: раз вы будете знать о возможностях Ora-cle Database 11g, то вы, скорее всего, измените метод написания кода уже сейчас!
Скажем, одна из наиболее важных новых возможностей PL/SQL в Oracle Database 11g - это кеширование результата PL/SQL-функции. Совершенно непроизносимая, однако, весьма отличительная возможность. В этой статье я предлагаю краткий обзор и подведение итогов обсуждения, как знание этой возможности может повлиять на написание PL/SQL-программ в более ранних версиях Oracle Database.
Предположим, что я работаю в команде, которая создает приложение по учету кадров. Таблица сотрудников - одна из основных структур, содержащая все данные обо всех сотрудниках. Сотни пользователей выполняют множество запросов в приложении, которое читает из этой таблицы и читает очень часто. Предположим, что таблицу изменяют относительно редко, примерно один-два раза в час. В результате код приложения периодически запрашивает блоки из буферного кеша, которые в основном постоянны, но выполняет дополнительную проверку, чтобы увидеть, прошел ли соответствующий запрос синтаксический анализ, разыскивая данные в буфере и возвращая их. Команда должна повысить производительность запросов данных из таблицы Служащих (employees). В настоящее время используется следующая функция, возвращающая строку таблицы employees:
FUNCTION one_employee (employee_id_in
IN employees.employee_id%TYPE)
RETURN employees%ROWTYPE
IS
l_employee employees%ROWTYPE;
BEGIN
SELECT *
INTO l_employee
FROM employees
WHERE employee_id = employee_id_in;
RETURN l_employee;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
/* Return an empty record. */
RETURN l_employee;
END one_employee;
Однако в Oracle Database 11g можно добавить строку в
заголовок этой функции, как показано ниже:
FUNCTION one_employee (employee_id_in
IN employees.employee_id%TYPE)
RETURN employees%ROWTYPE
RESULT_CACHE RELIES_ON (employees)
IS
l_employee employees%ROWTYPE;
BEGIN
.
Выражение RESULT_CACHE говорит Oracle Data-base, что следует запоминать (сохранять в специальном буфере результатов оперативной памяти) каждую запись, извлеченную для указанного ID сотрудника. И когда сессия выполняет эту функцию и передает ID сотрудника, который был сохранен ранее, ядро PL/SQL не выполняет тело функции, которое включает этот запрос.
Вместо этого просто извлекается запись из кеша, и данные сразу же возвращаются. В результате извлечение выполняется намного быстрее.
Кроме того, указав RELIES_ON (employees), мы информируем Oracle Database, что если какая-то из сессий зафиксирует изменения в этой таблице, все данные в кеше результата, помещенные из таблицы, будут инвалидными. Следующий вызов функции one_employee должен будет выполнить запрос и извлечь свежие данные из таблицы. Так как кэш - это часть System Global Area (SGA), его содержимое доступно всем сессиям, соединенным с экземпляром. Следовательно, Oracle Database будет применять к кешу свой алгоритм LRU ("least recently used" - "замещение наиболее давних по использованию данных"), чтобы гарантировать, что наиболее часто запрашиваемые данные будут сохраняться в кеше. До Oracle Database 11g похожий вид кеширования был возможен с коллекциями уровня пакета, однако, этот кеш - сессионный и расположен в Process Global Area (PGA). Это означает, что, если имеется 1,000 различных сессий работающего приложения, будет использоваться громадное количество памяти в дополнение к тому, что размещено в SGA.
Кеш результата PL/SQL-функции минимизирует количество памяти, требуемой для кеширования, и делает эти данные общими для всех сессий. Это ведет к уменьшению использования памяти, плюс к автоматической очистке кешированных результатов, когда бы ни выполнилась фиксация изменения, что делает эту возможность Oracle Database 11g очень полезной для оптимизации производительности PL/SQL-приложений. Анализ производительности и влияние PGA Для тестирования повышения производительности и влияния памяти PGA при повторяющихся запросов к данным, я разработал набор скриптов, доступных по ссылке otn.oracle.com/oramag/oracle/07-sep/o57plsql.zip, которые сравнивают три различных способа извлечения строк данных о сотрудниках:
- Неоднократное выполнение запроса;
- Кеширование всех строк таблицы employees в пакетной коллекции и затем извлечение данных из этого кеша;
- Использование кешированного результата PL/SQL-функции, чтобы избежать повторных запросов.
Для самостоятельного тестирования распакуйте файл o57plsql.zip и выполните скрипт 11g_emplu.tst. Он займет примерно пять или шесть секунд, и затем вы увидите примерно такие результаты:
PGA before tests are run:
session PGA: 910860 bytes
Execute query each time
Elapsed: 4.5 seconds.
session PGA: 910860 bytes
Cache table in PGA memory
Elapsed: .11 seconds.
session PGA: 1041932 bytes
Oracle Database 11g result cache
Elapsed: .27 seconds.
session PGA: 1041932 bytes
Приведу свои выводы на базе этого первоначального, не совсем полного эксперимента:
- кеширование результата PL/SQL-функции в Oracle Da-tabase 11g, конечно, намного быстрее, чем повторяющиеся запросы. В этом тесте показано, что кеширование более чем на порядок быстрее;
- кеш пакетных коллекций даже еще быстрее, в основном потому, что ядро механизма PL/SQL может получать доступ к данным в PGA, но не в SGA. Но, к сожалению, это также означает, что потребление памяти имеет место только в рамках сессии, и не очень масштабируется;
- метод с пакетными коллекциями расходует дополнительную память PGA, а кеш результата функции Oracle Database 11g - нет.Конечно, есть и другие важные достоинства возможности кеширования результата функции:
- автоматическая проверка статуса содержимого кеша, когда зависимая таблица изменяется;
совместное использование кеша сессиями; - применение приложением алгоритма замещения наиболее давних по использованию данных в кеше.
Почему нужно позаботиться уже сейчас? "Хорошо", - скажете вы себе. - "Классно! Но я не смогу использовать эти возможности еще два года или больше, что же я могу сделать сейчас?" У вас пока нет возможности использовать кеширование результата PL/SQL-функции, но уже сейчас можно написать код так, что когда в конечном итоге совершится переход на Oracle Database 11g, у вас будет возможность быстро и легко использовать кеширование в коде приложения. Другими словами, уже сейчас можно подготовиться к этой будущей возможности. Как это сделать? Замените все запросы (по крайней мере, к таблицам, которые изменяются редко, а запрашиваются часто) во внутренних функциях так, чтобы можно было легко добавить выражение RESULT_CACHE.
Подумайте об этом: скорее всего сегодня вы так не делаете. Вместо этого, при необходимости получить данные из базы данных вы пишете требуемый запрос непосредственно в приложении (где бы логика ни располагалась, в серверной части (в других PL/SQL-программах) или на клиенте (в
программах таких языков, как Java)).
И точно такой же запрос (или его небольшая вариация) будет появляться в различных местах кода приложения. Разве нет? Так легче написать SQL-предложения; ведь это одно из достоинств PL/SQL. Однако, легкость использования при выполнении SQL внутри PL/SQL признает SQL как
должное, а при переходе на Oracle Database 11g вы за это расплачиваетесь.
Если после обновления вы хотите получить преимущества RESULT_CACHE, необходимо будет найти все SQL-предложения, в каждом из них поместить подсказку оптимизатора RESULT_CACHE (это нормально, такая возможность доступна в SQL также, как и в функциях) или создать функцию, поместить в нее запрос, найти каждый соответствующий запрос приложения и заменить запрос на вызов функции.
Конечно, по сути оба эти подхода дублируют друг друга, но совершенно не хочется, чтобы пришлось их применять. IT-менеджеры ненавидят вникать в существующий, работающий производственный код и "путают карты", постоянно внося какие-то изменения. Если сделать наоборот и начать прямо сейчас в Oracle9i Database или Oracle Database 10g заменять запросы внутри функций, вы будете почти сразу же способны перевести код на использование фантастической возможности после перехода на Oracle Database 11g.
И, что лучше всего, код приложения, который вызывает функцию, не должен будет измениться вообще! Ваш менеджер будет очень доволен. Все это является поводом, чтобы изучать новые возможности Oracle Database 11g. Уже сегодня!