Том Кайт: о сервере Oracle Database 11g

Топ компании - oracle

Наш эксперт рассказывает о серверном кеше результатов выполнения запросов и кеше результатов вычисления функций PL/SQL.

В течение следующих нескольких месяцев я буду изучать новые функциональные возможности, появившиеся в самой последней версии сервера базы данных Oracle Database - Oracle Database 11g. Их так много, что трудно выбрать, с чего же начать. Поэтому я поговорил с Брином Лльюеллином (Bryn Llewellyn), менеджером по PL/SQL-продуктам, и он сообщил мне о паре прекрасных новых возможностях в языках SQL и PL/SQL.

Кешируйте

Сервер Oracle Database 11g поднимает планку кеширования данных. В прошлом сервер Oracle Database кешировал блоки базы данных. Он мог кешировать эти блоки в различных местах, таких как пул по умолчанию, удерживающий буферный пул или рециклирующий буферный пул. Но он всегда кешировал блоки данных - строительные блоки, используемые для построения результирующих наборов.

Начиная с Oracle Database 11g, сервер может кешировать результирующие наборы! Если у вас есть запрос, который многократно обращается к медленно изменяющимся или никогда не изменяющимся данным, вы обнаружите, что новый серверный кеш результатов выполнения запросов (server results cache) вызовет чрезвычайный интерес. Практически любое приложение может и будет получать выгоду от использования этого кеша.

Если кратко, идея такова: когда вы выполняете запрос, сервер Oracle Database 11g сначала выяснит, а не были ли результаты этого запроса уже вычислены и кешированы другим сеансом или пользователем, если это так, то он извлечет результат из серверного кеша результатов, вместо того, чтобы снова с нуля собирать все нужные блоки базы данных и вычислять результат. Для первого выполнения запроса потребуется столько же времени, сколько и обычно (поскольку вычисляется ответ), а последующие выполнения будут мгновенными, поскольку ответ не вычисляется, а сразу же возвращается.

Я считаю, что это средство аналогично динамическим материализованным представлениям (just-in-time materialized view). В сервере Oracle8i Database Release 1 корпорация Oracle ввела понятие материализованных представлений. С помощью такого представления АБД мог создать таблицу итогов, почти так же, как он создавал индексы, и оптимизатор распознавал, что эта таблица итогов существует и, если возможно, использовал ее для ответа на запросы, вместо того, чтобы запрашивать и обрабатывать детальную информацию, которая хранится в базовых таблицах. Этот способ работы хорош, но он скорее статический, очень похожий на схему индексирования. Однако в сервере Oracle Database 11g с помощью серверного кеша результатов материализованные представления создаются и сопровождаются в сущности на проходе . Этот кеш (динамическое материализованное представление) заполняется при необходимости, без какого-либо вмешательства АБД.

Еще хорошая вещь об этом - этот кеш автоматически делается недействительным и обновляется сервером базы данных, этот процесс совершенно прозрачен для приложения. Приложение не должно заботиться об устаревших или недействительных результатах.

Обратите внимание, что после выполнения оператора UPDATE для первого выполнения запроса снова потребовалось около 0.1 секунды, поскольку нужно было строить новый ответ. От этой работы получают выгоды последующие выполнения, которые кажутся мгновенными.

Я уверен, что, если вы удобно усядетесь и поразмышляете о ваших собственных приложениях, вы сможете найти более одного места, где пригодится серверный кеш результатов. Этот кеш предоставляет собой многие из преимуществ некоторых материализованных представлений, но не требует настройки и административных накладных расходов.

Постойте, это ещё не все...

Как говорят в ночных телепрограммах: Следующий сюжет удивит вас ещё больше! В сервере Oracle Database 11g есть также новый кеш результатов вычисления функций PL/SQL (PL/SQL function results cache). Если в вышерассмотренном серверном кеше результатов кешируются результирующие наборы SQL-операторов, то в этом новом кеше кешируются результаты вызовов функций и процедур PL/SQL.

Раньше, если вы вызывали PL/SQL-функцию 1 000 раз и каждый вызов потреблял 1 секунду, то для 1 000 вызовов требовалось 1 000 секунд. В зависимости от входных данных и изменения используемых данных, которые находятся в базе данных, кеш результатов вычисления функций позволяет выполнить 1 000 вызовов функции всего приблизительно за 1 секунду.

Вызовы функции с входным параметром SCOTT будут выполняться быстро до тех пор, пока кеш не должен будет сделан недействительным или же не закончиться выделенная для него память, которая понадобилась для других вызовов.

Кроме того, эту возможность можно реализовать без основательного изменения архитектуры приложений - фактически, совсем без изменения архитектуры. Эта возможность может быть активирована параметром компилятора, а выгоды будет получать любой клиент, который вызывает эту функцию. Например, неофициальные тесты в среде Oracle Application Express показали примерно 15-процентное уменьшение времени выполнения - конечно, у вас могут получиться другие результаты тестировани!

Если WHEN OTHERS, то ничего не возвращается

В выпуске этой колонки за июль-август 2007 (русский перевод: Том Кайт: об игнорировании, блокировании и разборах ) я писал о программной конструкции языка PL/SQL - обработчике исключительных ситуаций WHEN OTHERS. Я писал: В языке PL/SQL есть крайне нежелательная для меня программная конструкция WHEN OTHERS.

Я знаю, что корпорация Oracle никогда не будет устранять эту особенность языка, но сейчас она сделана более безопасной. Только чтобы напомнить, почему я хочу, чтобы эта программная конструкция не существовала, я снова процитирую себя:

Проблема заключается в том, что многие используют предложение WHEN OTHERS без последующего инициирования исключительных ситуаций (вызовы RAISE или RAISE_APPLICATION_ERROR). Это фактически скрывает ошибку. На самом деле ошибка происходит, но она не обрабатывается каким-то осмысленным образом, а просто игнорируется - молча. Вызывающий вашего кода не имеет никакого понятия, что случилось нечто чрезвычайное и ваш код сбился, обычно он думает, что на самом деле все работает успешно.

Много раз, очень много раз, нежели я могу вспомнить или сосчитать, причиной странного поведения программных модулей PL/SQL оказывалось ненадлежащее использование предложения WHEN OTHERS - за ним не следовал вызов RAISE. Ошибка скрывается, обработка ошибок фактически отключается, а в результате данные обычно логически разрушаются (приложение не делает свою работу) или получается неверный ответ.

Теперь в сервере Oracle Database 11g я легко могу найти кусок проблемного кода. Когда я полагаю, что была инициирована и скрыта исключительная ситуация, я быстро могу проверить мое подозрение.

Пустячок, а приятно…

Недаром говорят - пустячок, а приятно. Есть у меня напоследок одна мелочь, которая немного упрощает вашу программистскую жизнь, а язык PL/SQL делает немного более совершенным:

SQL> create sequence this_is_nice;

Sequence created.

SQL> declare

2    n number;

3  begin

4    n := this_is_nice.nextval;

5    dbms_output.put_line( n );

6  end;

7  /

1

PL/SQL procedure successfully completed.

Сравните это с тем, как такое нужно было делать в сервере Oracle Database 10g и предыдущих версиях. В сервере Oracle Database 11g не нужно больше выбирать последовательность из таблицы DUAL. Так что, язык PL/SQL стал намного более совершенным.

http://www.interface.ru/