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

Библиотечный кэш Oracle - это механизм, позволяющий пользователям совместно и многократно использовать SQL-предложения и PL/SQL-объекты, равно как и некоторые другие менее известные объекты. В процессе выполнения Oracle SQL-предложений или PL/SQL-блоков выполняется ряд сложных работ, в том числе:

• Разборка (parsing) SQL-предложений и PL/SQL-блоков
• Разрешение имен (расширение синонимов)
• Проверка по словарю данных достоверности имен объектов и столбцов, на которые имеются ссылки
• Авторизация привилегий пользователя на доступ или выполнение объектов
• Вызов оптимизатора Oracle для выработки плана выполнения SQL-предложений и PL/SQL-компилятора для анонимных PL/SQL-блоков.

Библиотечный кэш разделен на несколько регионов (или библиотек) в зависимости от типа кэшируемых в них объектов. Эти библиотеки также называются пространствами имен (namespaces). Перечислим некоторые из пространств имен:

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

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

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

Для мониторинга за производительностью библиотечного кэша Oracle в основном используются следующие коэффициенты:

Коэффициент 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.