Кэш словаря данных содержит строки, которые были прочитаны из словаря
данных в ответ на рекурсивные SQL. Данные из таблиц словаря данных считываются в буферный кэш базы данных (как и все остальные        а вся реле-

вантная информация пересылается в словарный кэш. Рекурсивные SQL выполняются в ответ на обычные SQL. Пока Oracle может разрешать рекурсив­ные SQL из кэша словаря данных, не возникает потребности в повторном счи­тывании с диска. Это означает уменьшение числа операций ввода/вывода. Приведенный ниже запрос поможет определиться с числом попаданий и, сле­довательно, подскажет, как часто система выполняет лишнюю работу:

SVRMGR> select to_char(

2>        round((1-sum(Getmisses)/sum(Gets))).100,

3>        D) ||  '%', "Hit Ratio"

4>       from V$ROWCACHE; Hit Ratio

89,8%

1 row selected. SVRMGR>

Ha практике мы обычно сталкиваемся с очень высокими коэффициентами попадания в словарный кэш (выше 90%). Для систем с менее высокими значени­ями этого коэффициента проблема обычно заключается в слишком малом раз­мере коллективного пула.

Oracle предлагает пакет        который способствует увели-

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

dbmspool.sql, 

размещенный в каталоге $ORACLE_HOME /rdbms/admin.

_] SQL> exec dbms_sfiared_pool.keepCSTANDARD'); PL/SQL procedure successfully completed.

После выполнения данной процедуры Oracle закрепит пакет в памяти. Неко­торые АБД проделывают это с очень большими пакетами, которые не настоль­ко часто применяются, чтобы быть закрепленными. Тем самым они с гарантией добиваются, что в любой момент пакет будет найден в памяти и при попытке за­грузить его не будет зарегистрирована ошибка. Пользуйтесь этой процедурой

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

Чтобы увидеть, что закреплено к настоящему моменту, познакомьтесь со­держимым столбца Kept представления V$DB_OBJECT_CACHE:

SVRMGR> select Owner,  Name, Type,  Sharablejiiem,
2>       from V$DB_0BJECT_CACHE
3>     where Type in  ('FUNCTION',   'PACKAGE'.
- 4>        'PROCEDURE')

5>    order by Owner,   Name;
OWNE    NAME        TYPE

Kept

'PACKAGE BODY'

SHARABLE MEM    KEP

SYS DBMS. APPLICATION.TNF'O
SYS        DBMS_APPLICATION_INFO

SYS       STANDARD

SYS     STANDARD 4 rows selected. SVRMGR>

PACKAGE

BODY

PACKAGE PACKAGE PACKAGE BODY

12873 2865 218604 28576

NO NO YES YES

Кроме того, имеется также возможность накалывать непоименованные объ-
екты типа курсоров (дескрипторов операторов SQL). Чтобы зафиксировать
курсор, нужно выбрать для него из представления        столбцы

ADDRESS и        а затем использовать их значения в качестве аргу-

ментов процедуры 

keep.

SQL> exec dbms_shared_pool.keep('21589568,413996079V ,'С'); PL/SQL procedure successfully completed.

Для получения более подробной информации о синтаксисе пакета DBMS SHARED_POOI. выполните команду desc с именем пакета в качестве аргумента.

Многие администраторы баз данных рекомендуют накалывать основные паке­ты системы сразу же после старта экземпляра. Таким образом появляется возмож­ность избежать проблем с этими пакетами и добиться того, чтобы они "наступали" на более мелкие объекты. Неплохо также идентифицировать все большие пакеты приложений и тоже наколоть их. К числу пакетов, которые чаще других рекомен­дуют для накалывания, относятся STANDARD, DBMS DESCRIBE, DBMS APPLICATION_INFO, DBMS STANDARD, DBMS OUTPUT и DBMS_UTILITY,

Они могут быть приколоты при запуске экземпляра от имени пользователя SYS, причем для этого не требуется никаких привилегий.

Когда мы проводили проверку для Oracle 8.1.6 (это справедливо и для других версий), выяснилось, что при сбрасывании коллективного пула не сбрасываются "приколотые объекты", т. е. объекты, для которых выполнена процедура keep. Такие объекты сбрасываются при явном выполнении команды unkeep.

Фрагментация коллективного пула: проактивное управление ошибкой ORA-04031

Кроме плохой производительности, обусловленной перезагрузками и неу­дачными попытками повторного использования SQL, еще одна наиболее часто встречающаяся претензия к коллективному пулу - его фрагментация. ORA-04031 - это единственный самый мощный оператор, с помощью которого Oracle пытается связаться с вами, чтобы вы проактивно управляли коллективным пу­лом и всеми относящимися к нему компонентами. Знакомство с некоторыми ис­точниками информации по Oracle дает множество полезной информации. Хотя не совсем так! Чтобы вы убедились в этом, ниже приводятся некоторые сведе­ния, почерпнутые из этих источников.

Причина  Требуется больше совместно используемой памяти, чем было распределено в коллективном пуле.

Действие  Если коллективный пул не умещается в памяти, либо используйте пакет DBMS_SHARED_POOL для прикалывания больших пакетов и        применения совместно используемой памяти,

либо увеличьте количество доступной совместно используемой памяти,

увеличив для этого значение параметров файла init.ora

SHARED_POOL_RESERVED_SIZE и SHARED POOL SIZE.

Если большой пул не умещается в памяти, увеличьте параметр INIT.ORA

LARGE_POOL_SIZE.

Теперь вы знаете столько же, сколько знали перед ошибкой. Вопрос в том,

какая из опций поможет решить проблему. Попробуем в этом разобраться. Что вызывает фрагментацию коллективного пула?

Скорость и частота фрагментации коллективного пула контролируется мно­гими вещами. Вот некоторые возмутители спокойствия:

Частое старение объектов из коллективного пула (это может быть проблема с размером пула)        у

Высокое значение показателя свободной памяти в V$SGASTAT

(если оно вызвано старением)

•        В коллективном пуле не сохраняются (KEPT) большие объекты

Много операторов SQL одного типа, которые не используют переменных связи

В Oracle 8.1.6 не используется С U RSOR_SHARLN'G, если не удается модифицировать приложение, чтобы оно использовало переменные связи

•        Избыточные разборки, частично в результате того, что не удается

закрепить (KEPT) в коллективном пуле большие объекты, а также

вследствие недостатка кэшнруемых курсоров в сеансах (не применяется SESSION_CACHED_CURSORS)

Много больших анонимных блоков PL/SQL

Не сконфигурированы и не используются резервный пул (Oracle 7.3 и более поздние версии) и большой пул (Oracle 8.0 и более поздние

версии)

Память под коллективный пул выделяется одним непрерывным куском. В процессе разборки первые пакеты и операторы захватывают память такими симпатичными непрерывными кусочками как раз того размера, который им не­обходим. После того как коллективный пул заполнился, Oracle пытается осво­бодить место для дополнительных объектов. При этом необходимо использовать алгоритм наиболее давно использовавшегося (LRU, least recently used) объекта для управления пространством в коллективном пуле.

Oracle выбрасывает самые давно использовавшиеся объекты. Поскольку

объекты загружались по принципу "первым загрузился, первым обслужен", а во­все не в порядке их использования в будущем, коллективный пул становится по­хожим на швейцарский сыр. Самые новые операторы вставляются, как в сырные дырки, в свободные промежутки. Но вот приходит пакет размером с Гаргантюа (если кто забыл, напоминаем: великан Гаргантюа - один из главных героев книги Франсуа Рабле "Гаргантюа и Пантагрюэль". - 

Прим. пер.), 

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

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

Обычно в таких случаях проектировщики звонят инвестору и объявляют ему ORA-04031: "unable to allocate %s bytes of shared memory".