Что такое этот Buffer Cache (буферный кеш)?

dbstalker, 16 мая

  • Это составная часть SGA
  • Используется для быстрого доступа к данным
  • Использует LRU алгоритм, для того чтобы лишаться непопулярных данных
  • Содержит внутренние структуры: Default buffer pool, Keep buffer pool и Recycle buffer pool
  • Параметром DB_CACHE_SIZE устанавливается размер

Это самая большая составляющая области SGA. Поскольку буферный кеш принадлежит SGA,то буфера доступным всем пользователям. В буферном кеше сервер Oracle хранят блоки базы данных после считывания с диска. Буферный кэш содержит только буфера, но не управляющие структуры. Для каждого буфера есть соответствующий буферный заголовок в переменной области SGA. Аналогично, working set headers, the hash chain headers и их защелки также находятся в переменной области SGA. Очевидно, что оперировать данными, находящимися в памяти, значительно быстрее, чем с данными находящимися на диске. Поэтому главная задача буферного кеша – минимизация физического ввода - вывода. Оракл исходит из того, что если блок данных прочитан, то он, скорее всего, может понадобиться снова. Конечно, идеальным вариантом в этом контексте может быть размер буферного кеша на столько большой, что в нем помещаются все блоки данных, с которыми предстоит работать на протяжении дня. Но так никогда не бывает. Поэтому в результате работы экземпляра в буферном кэше сохраняются наиболее востребованные блоки данных. И как следствие, при обработке данных возможны два варианта развития событий:

  • Если необходимые данные находятся в кеше, то оракл обрабатывает их, не обращаясь к файлам данных (cache hit) –«попадание»
  • Если необходимые данные не находятся в кеше, оракл вынужден читать блоки из файлов данных (cache miss) – «промах»

Для повышения производительности серверный процесс иногда читает несколько блоков за одну операцию чтения. С этой же целью процесс DBWn записывает несколько блоков за одну операцию записи.

Буферный кеш состоит из буферов, которые могут пребывать в следующих состояниях:

  • Clean (чистые) буфера - означает, что буфер в настоящее время не закреплен (unpinned) и является кандидатом на удаление из кэша, если на его содержимое не буде опять ссылок. Содержимое буфера либо синхронизировано с блоком на диске, либо буфер использовался для генерации и обработки старого моментального снимка блока в режиме целостного чтения (Consistent read – CR блок)
  • pinned буфера («закрепленные») - означает, что несколько сеансов не могут в один и тот же момент времени писать в один блок и вынуждены ждать доступа к блоку
  • free/unused (свободный/неиспользуемый) – означает, что буфер пустой, т.к. экземпляр только что был запущен. Состояние очень похоже на Clean, за исключение того, что буфер еще не использовался.
  • Dirty («грязный») – буфер больше не является закрепленным, но его содержимое было изменено и должно быть записано на диск процессом DBWR перед удалением из кэша.

В произвольный момент времени кеш буферов может содержать несколько копий одного и того же блока базы данных. Только одна из них является текущей, остальные конструируются на основе сегментов отмены (construct read-consistent copies from past image information -CR block. Они обеспечивают целостные чтения данных.

Упрощенно можно утверждать, что для управления буферным кешем оракл использует два списка:

  • Список грязных буферов (Dirty List , Write List, LRUw, checkpoint queue)
  • Список чистых буферов (LRU)

Список «грязных» буферов (checkpoint queue) содержит перечень указателей на модифицированные ( командами insert, update, delete) буфера, которые необходимо записать на диск в файл данных. Запись производится фоновым процессом DBWR.

Список «чистых» буферов используется для того, чтобы удержать в памяти как можно дольше популярные блоки данных для минимизации затрат на операции ввода-вывода. Более детально можно прочитать в посте «Немного об LRU списке».

Во время поиска свободного буфера для сохранения прочитанного блока пользовательский серверный процесс использует оба списка: LRU List и Dirty List:

  • Пока сканируется LRU List в поиске свободных буферов, серверный процесс перемещает dirty блоки, которые попались на пути поиска по LRU в Dirty список.
  • При каждом добавлении грязный список возрастает. Когда его размеры превысят установленный порог, процесс DBWR начинает запись модифицированных буферов на диск.
  • Но DBWR может начать запись модифицированных буферов, не дожидаясь превышения этого порога. Это становится возможным, если серверный процесс просмотрел слишком много буферов и не нашел свободного. В этом случае грязные буфера пишутся напрямую из LRU списка на диск (без предварительного переноса в Dirty список).

Буферный кеш в версиях до Oracle 8.0 представлял собой один большой кеш. Все блоки кешировались одинаково. В Oracle 8.0 добавлена возможность создания буферных пулов.

По умолчанию всегда создается DEFAULT BUFFER POOL (параметр db_cache_size) . Содержит все данные, которые специально не закреплены в других пулах.

KEEP BUFFER POOL (параметр db_keep_cache_size) – пул для наиболее востребованных блоков. Используется для размещения целиком небольших таблиц, которые часто используются (например, справочники). Специфика пула – данные постоянно в нем находятся, а не выбрасываются со временем из него как устаревшие. Вернее сражение за право остаться в этом пуле происходит только между таблицами, закрепленными именно за этим пулом, а не со всеми данными. Буфера управляются в пуле также как и в DEFAULT BUFFER POOL (own LRU list and checkpoint queue) . Что бы получить эффект от использования этого пула - установите правильный размер.

RECYCLE BUFFER POOL (параметр db_recycle_cache_size) – блоки, помещенные в этот пул, сразу же после использования удаляются из него (после завершения транзакции). Эффективно для работы с большими таблицами, если вероятность повторного использования блока незначительна. Нет смысла удерживать такую информацию в пуле.Буфера управляются в пуле также как и в DEFAULT BUFFER POOL (own LRU list and checkpoint queue

Чтобы блоки Вашей таблицы попали в пул KEEP или RECYCLE нужно явно назначить пул для этой таблицы. Иначе, по умолчанию она попадет в DEFAULT.

alter table my_table1 storage (BUFFER_POOL KEEP);
alter table my_table2 storage (BUFFER_POOL RECYCLE);

Так как все пулы (default, recycle, keep) управляются одинаково, то размером холодной и горячей части LRU-списков так же управляют аналогичные параметры:

  • _db_percent_hot_default
  • _db_percent_hot_keep
  • _db_percent_hot_recycle

В Oracle 10g появились параметры:

  • DB_2K_CACHE_SIZE
  • DB_4K_CACHE_SIZE
  • DB_8K_CACHE_SIZE
  • DB_16K_CACHE_SIZE
  • DB_32K_CACHE_SIZE

Эти параметры (db_nn_cache_size) используются для создания отдельных пулов буферов данных, которые используются для разделения (segregate) данных и изолирования (isolate) объектов с различными характеристиками ввода/вывода. Таким образом, для работы с блоками иного размера, нежели установленного параметром DB_BLOCK_SIZE, можно создавать соответствующие пулы.

Параметр DB_BLOCK_SIZE всегда используется для создания файлов данных SYSTEM, SYSAUX и temporary табличных пространств. Это изменить никогда нельзя.

Параметры db_nn_cache_size не могут использоваться для задания размера кэша с буферами, равными стандартному размеру блока. Если значение DB_BLOCK_SIZE равно nK,тогда нельзя задать параметр db_nК_cache_size. Размер кэша с буферами стандартного размера всегда определяется параметром DB_BLOCK_SIZE.

Пулы keep и recycle могут работать только с блоками, размер которых в экземпляре установлен по умолчанию.

«Нетрадиционные» блоки содержатся в специально созданных табличных пространствах. Например:

CREATE TABLESPACE TEST_DATA_16K  LOGGING    DATAFILE  'C:\ORACLE\ORADATA\SAM\TEST_DATA_16K.ORA'  SIZE 100M   BLOCKSIZE 16384      EXTENT MANAGEMENT LOCAL

О размере блока в существующих табличных пространств можно узнать из выборки:

SELECT TABLESPACE_NAME, BLOCK_SIZE  FROM DBA_TABLESPACES;

Еще несколько полезных запросов:

SELECT TABLE_NAME, CACHE, BUFFER_POOL     FROM USER_TABLES    ORDER BY TABLE_NAME;
select name, value, isdefault, ismodified from v$parameter where name ='db_cache_advice' or name ='db_cache_size';

На последок хотелось бы сказать, что не так все просто с буферным кэшем, как тут все описано. Существует в оракле такое понятие как WORKING SETS(WS). Буфера в буферном кэше распределены по этим WORKING SETS, то есть WS - это подмножество буферов в буферном кеше. Каждый WS связан с одним процессом DBWn, защищен своей cache buffers lru chain защелкой, имеет свои списки LRU и checkpoint queue .Описание WS можно найти в таблице X$KCBWDS. Количество WS зависит от количества процессоров (CPU) в системе и количества сконфигурированных фоновых процессов DBWR.В свою очередь пулы состоят из набора WS. Об этом - в таблице X$KCBWBPD. Ясно, что все это организовано для повышения производительности.Для чего ж еще? Параллельная работа на различных процессорах проходит без конкурентной борьбы благодаря тому, что каждый использует свой WS.

Литература

http://citforum.univ.kiev.ua/database/oracle/kyte/02.shtml

http://www.praetoriate.com/t_oracle_data_block_caching_sga.htm

http://citforum.univ.kiev.ua/database/oracle/kyte/02.shtml

www.dcopeland.net/files/IT453chapter02buffercache.ppt

http://advait.wordpress.com/2007/06/13/tuning-buffer-cache-oracle-database-10g/

http://www.praetoriate.com/t_%20tuning_data_buffer_hit_ratio.htm

Тэги: SGA

ОднаКнопка

2 комментария

Прокоментировать

Влад
18 февраля 2009 г. в 15:18

Хорошая статья, а то по инету по крупицам собирать приходится. Надеюсь, что информация в этом блоге поможет в решении моих задач.

MADI
11 апреля 2012 г. в 06:34

СУПЕР СПС !!!

 

Новый комментарий

Я не спамер: введите суму 5+3



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Нужна гадалка
20 июля, 1 ответа
Бутель для воды
20 июля, 1 ответа