Конфигурируется аналогично пулу сохранения. Параметр BUFFER_POOL_ RECYCLE устанавливается на какое-то количество буферов и некоторое число защелок:

J   BUFFEH„POOL_RECYCLE =   (buffers: 1000,   lru.latcrierl)

Здесь для пула повторного использования распределяется 1 тысяча блоков из 10 тысяч (общего числа, на которое установлен параметр DB_BLOCK_ BUFFERS) доступных пулам кэша буфера базы данных и одна из защелок LRU, предназначенных для управления этими блоками. Распределите в этот пул боль­шие объекты. Доступ к ним, вероятно, будет производиться с некоторой часто­той, и они могут заставить другие объекты устаревать, не дожив до старости (или, по-другому, заставляют их умирать не своей смертью. - 

Прим. тф.). 

Боль­шими объектами следует называть такие, доступ к которым осуществляется слу­чайным образом и которые объясняют значительный процент случайных чтений. Определение термина "значительный" является специфическим для

каждого приложения и базы данных. Рекомендуется назначать в пул повторного использования объекты с числом операций чтения блоков (логических чтений)

приблизительно равным числу физических операций чтения. Соотношение примерно один к одному между логическими и физическими чтениями является хорошим индикатором того, что этот объект ничего не выиграет от кэширова­ния. Скорее всего, он вызовет вытеснение из кэша по умолчанию (по причине старения) других важных объектов, если они разделяют с ним один и тот же пул. Чтобы идентифицировать такие таблицы, необходимо выполнить запросы ко всем подозрительным таблицам с включенной опцией автотрассировки, а за­тем выполнить tkprof, чтобы сравнить число физических и логических опера­ций чтения, либо просмотреть для этого представления VSCACHE и V$BH.

Экземпляр не сможет стартовать, если не определено число защелок для пулов сохранения и повторного использования. Кроме того, заметьте, что число буферов в пуле по умолчанию должно быть равно (DB_BLOCK_BUFFERS-(BUFFER_POOL_KEEP+BUFFER_POOL_RECYCLE)). Аналогичные вычисления нужно провести для защелок в пуле по умолчанию, пока имеется по крайней мере 50 буферов на одну защелку. Динамическое представление производительности V$BUFFER_POOL предлагает информацию о том, сколько буферов распределено для каждого из пулов.

Для того чтобы информация, содержащаяся в представлениях V$CACHEnV$BH, была точной, необходимо всякий раз, когда в базу данных добавляется (или удаляется) объект, выполнять сценарий catparr.sql, размещенный в каталоге $ORACLE_HOME/rdbms/admin. ■

Пул для хранения объектов может быть выбран при их создании. Например:

create table EMP СEmpic number,

Lname varchar2(30),

Fname varchar2(30),

Salary nuinber(8,2)) tablespace EMPDATA01 storage (buffer_pool keep);

Здесь для таблицы ЕМР назначен пул keep. Если параметр 

buJfir_puoli 

специ­фицирован, объект размещается в пуле по умолчанию. Объект также может быть преобразован за счет изменения значения атрибута 

buffer_pocdo 

фразе sto­rage оператора alter.

Данная опция является еще одним атрибутом сегмента, изменяющим способ управления Oracle присутствием сегмента в кэше буфера базы данных. Это вер­но прежде всего для версий базы данных, появившихся до OradeS. Опция осо­бенно влияет на таблицы, для которых проводится полное сканирование таблицы. По умолчанию cache при создании объекта является выключенной, ес­ли она не специфицирована явным образом. Это приводит к тому, что во время полного сканирования таблицы блоки этого сегмента добавляются к наиболее

давно использовавшемуся концу списка LRU (напоминаем, этот алгоритм изме-
нен в        Это хорошо, потому что не нужно очищать кэш перед проведе-
нием полного сканирования таблицы. Но плохо, если сегмент используется
часто и доступ к нему выполняется только путем полного сканирования табли-
' цы, что бывает в случае небольших таблиц. Значит, если атрибут 

cachene 

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

При создании или изменении сегмента атрибут 

cache 

можно включить. На­пример, команда alter table EMP cache; включает кэширование для таблицы ЕМР. Теперь всякий раз при выполнении полного сканирования таблицы для таблицы ЕМР блоки будут добавляться к наиболее недавно использовавшемуся (MRU) концу списка LRU. В таком случае возрастает вероятность, что таблица ЕМР останется в кэше буфера базы данных. Но в то же время это может привес­ти и к блокировкам по старению для других таблиц, которые оказываются ли­шенными возможности расчистить место новым блокам. Следовательно, таблица ЕМР с атрибутом cache должна теперь рассматриваться на предмет раз­мещения в пуле keep.