Джон Березниевич (корпорация Savant)

Эта статья впервые была размещена на сайте http://www.oramag.ru/

Что такое библиотечный кэш?

Библиотечный кэш Oracle – это механизм, позволяющий пользователям совместно и многократно использовать SQL-предложения и PL/SQL-объекты, равно как и некоторые другие менее известные объекты. В процессе выполнения Oracle SQL-предложений или PL/SQL-блоков выполняется ряд сложных работ, в том числе: Разборка (parsing) SQL-предложений и PL/SQL-блоков Разрешение имен (расширение синонимов) Проверка по словарю данных достоверности имен объектов и столбцов, на которые имеются ссылки Авторизация привилегий пользователя на доступ или выполнение объектов Вызов оптимизатора Oracle для выработки плана выполнения SQL-предложений и PL/SQL-компилятора для анонимных PL/SQL-блоков. Для выполнения этих работ может потребоваться значительное количество ресурсов CPU и памяти, так что библиотечный кэш был разработан для того, чтобы позволить кэширование результатов этих работ на тот случай, если другие пользователи пытаются выполнять те же самые SQL-предложения или PL/SQL-блоки. Для большинства приложений характерно, что в процессе нормальной обработки множеством пользователей неоднократно выполняются одни и те же SQL-предложения. Таким образом, сохранив результаты в кэше и сделав их доступными для немедленного просмотра при последующих выполнениях, можно существенно повысить производительность Oracle. Вы можете считать, что в отличие от буферного кэша, который является исключительно кэшем данных, библиотечный кэш является в основном кэшем исполняемого кода.

Библиотечный кэш разделен на несколько регионов (или библиотек) в зависимости от типа кэшируемых в них объектов. Эти библиотеки также называются пространствами имен (namespaces). Перечислим некоторые из пространств имен: SQL AREA = Совместно используемые курсоры SQL-предложений TABLE/PROCEDURE = Определения таблиц и спецификации хранимых программ PL/SQL (процедур, функций или пакетов) BODY = Тела хранимых PL/SQL-программ (процедур, функций и пакетов) TRIGGER = Табличные триггеры на PL/SQL INDEX = Стандартные индексы CLUSTER = Кластеры таблиц OBJECT = Объекты Oracle8 PIPE = Каналы базы данных Объекты библиотечного кэша

Разделяемые курсоры SQL, PL/SQL и другие объекты хранятся в библиотечном кэше в сложной структуре, называемой объектом библиотечного кэша. Объекты библиотечного кэша составлены из нескольких частей, каждая из которых занимает один или несколько кусков памяти в разделяемом пуле. Объект имеет заголовок, который, по существу, является идентификатором объекта. Он содержит "дескриптор" (“handle”) объекта в кэше, а также текст SQL или PL/SQL-блока. Именно нахождение заголовка является результатом логического чтения библиотечного кэша, которое выполняется всякий раз, когда пользователь посылает для выполнения в Oracle SQL-предложение. Результат "Gethit" (попадание, удача) означает, что этот объект ранее был загружен в библиотечный кэш и его дескриптор идентифицирован.

Другие компоненты объекта библиотечного кэша могут быть разными в зависимости от типа объекта, но каждый из них индивидуально распределен в кусках разделяемого пула памяти. Когда объект библиотечного кэша выполняется, все связанные с ним в разделяемом пуле части закрепляются на время выполнения. Если эти куски памяти не закреплены (объект не выполняется), они могут быть удалены (механизм LRU) из разделяемого пула в случае требования памяти от других потребителей разделяемого пула. Таким образом, вполне возможно, что заголовок библиотечного кэша существует, но одна или несколько связанных с ним компонент библиотечного кэша вытеснены из пула. В этом случае запрос на закрепление объекта потребует перезагрузки объекта в кэш. Перезагрузка – это дорогое действие, поскольку при этом требуется повторно создавать объект библиотечного кэша, и ее можно было бы избежать, если запретить вытеснение компонент объекта из разделяемого пула.

Коэффициенты производительности библиотечного кэша

Для мониторинга за производительностью библиотечного кэша Oracle в основном используются следующие коэффициенты: Коэффициент GetHit Коэффициент PinHit Коэффициент Reload/Pin. Вы можете получить значения этих коэффициентов, сделав запрос к виртуальной таблице V$LIBRARYCACHE, или использовав соответсвующий экран (Library Cache Details List) Diagnostic Center (рекомендуется).

Коэффициент GetHit

Большинство систем должно иметь очень высокий коэффициент GetHit – более 95 % для наиболее часто используемых пространств имен. Низкие значения этого коэффициента обычно являются результатом недостаточного совместного использования курсоров SQL и PL/SQL. В этом случае приложение SQL должно быть исследовано на предмет плохого использования связываемых переменных(то есть, SQL-литералов). Компанией Savant специально разработан продукт Profiler, который помогает идентифицировать SQL-предложения, в которых вместо связываемых переменных используются литералы.

Коэффициент PinHit

Коэффициент PinHit указывает, сколько раз пользователи фактически запрашивали и имели возможность использовать и выполнить объекты библиотечного кэша, благодаря тому, что эти объекты были закреплены для выполнения. Подобно коэффициенту GetHit, его значение должно быть очень высоко (95% или больше) для пространств имен, к которым имеется весьма большое число логических чтений (GET). Если значение этого коэффициента низкое, то это, вероятнее всего, происходит из-за большого количества SQL-предложений, не использующих разделяемые ресурсы.

Коэффициент Reload/Pin

Это, вероятно, наиболее важный из трех перечисленных выше коэффициентов. Если имеется значительное число перезагрузок, это значит, что части объектов библиотечного кэша удаляются из разделяемого пула, а затем заново загружаются другими процессами. При этом перезагрузка происходит с диска, а это всегда дорогая операция. Следует провести в режиме SIGMA мониторинг библиотечного кэша, используя Library Cache Details List Диагностического центра, чтобы составить представление, имеется ли вообще существенное число перезагрузок. Режим DELTA с малыми интервалами регенерации не может дать достаточно большую выборку закреплений конкретных объектов, однако, если мониторинг в режиме DELTA показывает существенное число перезагрузок, то почти всегда производительность системы поставлена под угрозу.

Если коэффициент Reload/Pin превышает 1-2 %, может помочь увеличение значения параметра инициализации SHARED_POOL_SIZE.

Объекты библиотечного кэша, которые используются регулярно, но нечасто (и помечаются как закрепленные в кэше на время исполнения), должны быть постоянно закреплены в разделяемом пуле с использованием процедуры DBMS_SHARED_POOL.KEEP. Отметим, что эту процедуру можно также вызывать для разделяемых курсоров, так что все, что повторно используется, теоретически можно закрепить в пуле и защитить от старения по LRU и перезагрузок.

Я надеюсь, что эта небольшая статья поможет разъяснить основное назначение библиотечного кэша Oracle, а также обеспечит некоторое понимание того, как он работает, и на что можно надеяться в плане настройки. Рассмотрение реального алгоритма работы выходит за пределы данной статьи, тем более что он в значительной степени остается закрытой служебной информацией корпорации Oracle.

Об авторе

Джон Березневич – почетный соучредитель и технический менеджер продуктов корпорации Savant. Он является одним из основных дизайнеров и разработчиков Диагностического центра для Oracle корпорации Savant. Джон также является соавтором книг Oracle Built-in Packages и Oracle PL/SQL Built-ins Pocket Reference (издательство O'Reilly & Associates). Кроме того, он популярный и частый докладчик на больших и малых конференциях Oracle.