Инкрементальная контрольная точка

dbstalker, 10 декабря

До версии 8.1 ораклом поддерживалась нормальная контрольная точка. Её выполнение являлось очень значительной пиковой нагрузкой на сервер. Оракл решил побороть эти негативные явления. Так появилось понятие инкрементальной контрольной точки. Она выполняет основное требование к контрольным точкам – уменьшает время восстановления после сбоя экземпляра. Но, и это главное, не вызывает пиковых нагрузок на систему.

Отличительные черты инкрементальной точки:

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

Технология выполнения изображена на следующем рисунке:

  1. Серверные процессы пользователей генерируют redo-информацию в log buffer.
  2. Процесс LGWR периодически записывает информацию из log buffer в текущий оперативный журнальный файл. RBA (Redo Byte Address) последнего записанного блока называется on disk RBA. On disk RBA,так называемая, «голова» очереди checkpoint queue (см. ниже) указывает на блок, до которого DBWR может записывать грязные блоки на диск, так как они уже защищены журнальным файлом.
  3. LGWR записывает RBA последнего записанного redo-блока в поле on disk RBA структуры, отражающей в оперативной памяти образ checkpoint progress record управляющего файла. За этой структурой можно наблюдать посредством таблицы x$kcccp.
  4. По мере появления грязных блоков процесс DBWR формирует в дополнение к LRU - очереди (формируется по времени последнего обращения) еще и очередь по порядку модификации блоков checkpoint queue из связанных в упорядоченный по возрастанию low RBA список этих блоков. Low RBA – это redo-адрес первого изменения блока, сделавшего его “грязным”. То есть формируется очередь по редо-адресам первых изменений загрязнивших блок. Размер checkpoint queue регулируется различными параметрами: от старых LOG_CHECKPOINT_INTERVAL и LOG_CHECKPOINT_TIMEOUT до новых FAST_START_IO/MTTR_TARGET.
  5. В какой-то момент времени DBWR определяет, что один из параметров, управляющий наступлением инкрементальной контрольной точки, превысил свое пороговое значение, то есть размер очереди изчерпался. Начинается выполнение инкрементальной контрольной точки. DBWR вычисляет target RBA - тот редо-адрес блока из checkpoint queue, до которого будет осуществлена запись блоков на диск. Target RBA должен быть таковым, чтобы после выполнения инкрементальной точки параметр, который вызвал её выполнение, принял допустимое значение. Target RBA не обязательно должен равняться on disk RBA, то есть не обязательно чтобы все блоки из очереди checkpoint queue были сброшены на диск.
  6. DBWR записывает все блоки из checkpoint queue от ее начала до target RBA включительно в файлы данных. Записанные на диск грязные блоки из буферного кэша не выбрасываются, а только становятся чистыми.
  7. По окончании записи всех “грязных” блоков до target RBA включительно процесс DBWR записывает адрес следующего за target RBA в checkpoint queue блока (или последнего блока из checkpoint queue, если оттуда были записаны все блоки) в качестве low cache RBA(«хвост очереди») в x$kcccp (перемещает recovery-маркер). Это означает, что для восстановления экземпляра в случае сбоя, нужны будут только журнальные файлы, которые содержат данные, начиная с этого low cache RBA(«хвоста»). Именно в этот момент активный журнальный файл становиться неактивным при условии, что «хвост» очереди перейдет в следующий журнальный файл.
  8. Процесс CKPT, активизирующийся каждые 3 секунды, увеличит на 1 счетчик checkpoint heartbeat в x$kcccp (select cphbt from x$kcccp), а так же
  9. обновит в управляющем файле checkpoint progress record значением из checkpoint structure in memory (проекция в x$kcccp). Таким образом, в управляющем файле появляется информация о «хвосте» очереди checkpoint queue – самом первом по времени измененном блоке, защищенном журналом, но не сброшенном на диск. Важно, что эта операция не является транзакцией управляющего файла. Теперь очевидно, что информация о прошедшей инкрементальной контрольной точке максимум через 3 секунды попадет в управляющий файл.

Таким образом, выполнение инкрементальной точки – только выполнение шагов 5,6,7. Для DBWR операции ввода-вывода при выполнений инкрементальной точки являются низкоприоритетными. Поэтому контрольная точка не является ресурсоемкой нагрузкой на систему и , в этом контексте, является фактором повышения производительности системы.

Также можно к её преимуществам отнести следующее:

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

В тоже время негативное влияние инкрементальных точек может быть вызвано только излишней частотой их выполнения. Поэтому необходимо настроить работу экземпляра таким образом, чтобы инкрементальная контрольная точка выполнялась не слишком часто: важен размер журнальных файлов, значение параметром инициализации - FAST_START_MTTR_TARGET, LOG_CHECKPOINT_TIMEOUT и LOG_CHECKPOINT_INTERVAL. Так же нужно обратить внимание на ситуацию когда обновляются одни и те же блоки, они же постоянно буду сбрасываться на диск.

И на последок, на базе oracle 10g под Linux проверено следующее:

Alter system switch logfile - не выполняется нормальная контрольная точка – не обновляются заголовки файлов данных

Alter system checkpoint – выполняется нормальная контрольная точка - обновляются заголовки файлов данных

Можно проверить по представлению select CHECKPOINT_CHANGE#,CHECKPOINT_TIME from v$datafile_header

К сведению:

Инкрементальные контрольные точки не фиксируются ни в alert-файле, ни в статистиках DBWR checkpoints, background checkpoints started, background checkpoints completed. Они находят отражение только в статистике DBWR checkpoint buffers written. В alert-файл и в вышеуказанные статистики записываются только контрольные точки по переключению журнала и по оператору ALTER SYSTEM CHECKPOINT(то есть нормальные точки).

Здесь мною использовалась информация из очень многих источников, но больше всего почерпнуто из http://www.oracle.com/global/ru/oramag/aug2005/admin_check_point.html. Большое спасибо всем источникам! А Вам успехов в труде и личной жизни!

Размер Checkpoint queue можно увидеть так:

select * from V$SGASTAT where name like '%Checkpoint queue%'
select * from x$ksmss where KSMSSNAM like '%Checkpoint queue%'

 

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

Я не спамер: введите суму 7+8



 

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

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

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

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


 
 

Бизнес форум

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

Микрофон
19 августа, 2 ответа
Сумочка
19 августа, 2 ответа
средства для рук
17 августа, 3 ответа