Сообщение в alert.log: Checkpoint not complete

dbstalker, 19 декабря

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

Если коротко: возникновение сообщения «Checkpoint not complete» возможно по двум причинам:

  1. контрольная точка не завершила сброс грязных блоков, защищенных этим журналом. Возникает ожидание занятой контрольной точки (checkpoint busy wait)
  2. процесс ARCH не завершил архивировать журнал, на который должно произойти переключение. Возникает ожидание занятого процесса архивирования (archiver busy wait)

А теперь несколько глубже в контексте первого пункта :

Задача журналов повторного выполнения – в случае сбоя экземпляра сделать невозможной потерю данных, которые находятся в в оперативной памяти (в буферном кэше) и пока что не сброшены на диск в файлы данных.

Количество таких («грязных») блоков ограничено размером буферного кеша. Поэтому грязные блоки нужно периодически сохранять в файлах данных. Процесс сброса грязных блоков в файлы данных называется контрольной точкой.

При переключении журнала повторного выполнения начинается обработка контрольной точки log switch checkpoint. Для версий до 8.1 – это нормальная контрольная точка. Для более высоких версий это низкоприоритетная нормальная контрольная точка (переключение журналов не вызывает выполнение инкрементальной контрольной точки).

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

Если же

  • общий объем пространства в журналах повторного выполнения очень уж небольшой по сравнению с размером буферного кэша
  • информация повторного выполнения генерируется со значительной интенсивностью,

то процесс LGWR может быстро заполнить все файлы журнала повторного выполнения значительно раньше, чем процесс DBWn завершит все операции записи на диск, вызванные обработкой контрольной точки log switch checkpoint и защищаемые журналом на который должно произойти переключение.

LGWR работает быстрее, чем DBWn:

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

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

Процессы, генерирующие информацию повторного выполнения, будут ждать события переключения журнала, то есть завершения обработки контрольной точки, и в файл alert.log будет выдано сообщение следующего вида.

Thread 1 cannot allocate new log, sequence 82315 
Checkpoint not complete

До версии 8.1 выполнялась нормальная контрольная точка, которая вызывала значительную пиковую нагрузку на систему. Если производились массовые изменения в базе за короткий промежуток времени, то процесс DBWR может не успеть сбросить необходимые грязные блоки на диск. То есть все существующие журналы имеют статус «ACTIVE» или «CURRENT». Журнала уже ненужного для восстановления нет в системе.

Для версии 8.1 и выше ошибка "Checkpoint not complete" возникает при несколько других обстоятельствах. По ходу работы сервера, можно сказать, одна за другой выполняются инкрементальные контрольные точки, которые равномерно (без пиковых нагрузок) сбрасывают грязные блоки на диск. Но при переключении журналов выполняется низкоприоритетная контрольная точка, которая заканчивает свою работу только тогда, когда очередная инкрементальная точка сбросит все грязные блоки, защищаемые журналом, с которого система переключилась. При такой технологии вроде бы и не должно возникать "Checkpoint not complete", но практика показывает, что все в жизни возможно. Для процесса DBWn записи, вызванные обработкой контрольной точки при переключении журналов, являются низкоприоритетными. Поэтому информация из очереди контрольной точки (checkpoint queue) выбирается для дополнения других пакетов записей.

Во всех этих двух случаях результат один: если оракл хочет писать в активный (ACTIVE) журнальный файл, то возникает ожидание "Checkpoint not complete". Система не будет производить никакие изменения до тех пор, пока путем записи грязных блоков на диск, этот журнал не приобретет неактивный (NOACTIVE) статус и будет не нужен для восстановления экземпляра после сбоя.

Таким образом, оракл не будет перезаписывать журнальный файл нужный для восстановления. Проверка «нужности» журнального файла происходит приблизительно так:

Оракл проверяет scn# самого старого блока в checkpoint queue (очереди контрольной точки) и анализирует или этот номер больше или меньше, чем самый большой scn#" в редо-логе, который LGWR пытается перезаписывать. Если номер меньше, чем самый большой scn#" редо-лога( хвост ещё находится в журнале), тогда оракл защищает файл от перезаписи. Так как если сбой системы произойдет прямо сейчас, то информация из этого файла нужна будет для восстановления, потому что восстановление начнется с самого старого блока из checkpoint queue .

Частоту возникновения ситуации, когда контрольная точка не завершается до начала следующей можно отследить, сравнивая значения статистик

background_checkpoints_started и background_checkpoints_completed из v$sysstat.

Если разница значений превышает 1, то контрольная точка не завершались к началу новой контрольной точки.

Как возникает проблема уже, наверное, ясно. Как с этим бороться?

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

Есть разные варианты в зависимости от нагрузки вашего сервера:

  • Размер буферного кеша и размер журнальных файлов должен быть соизмерим. Неплохо было бы, чтобы все блоки из буферного кеша помещались в одном журнальном файле (если это возможно).
  • Количество групп журнальных файлов должно быть достаточным для полного круга . Наверняка, больше двух.
  • Отладить частоту выполнения контрольной точки, установив соответствующие параметры в допустимых границах.
  • оптимизации работы процессов DBWn,

А теперь в контексте второй причины возникновения освещаемой проблемы:

Событие ожидания занятого процесса архивирования обычно возникает при генерации большого числа транзакций во время пакетной обработки, когда скорость записи redo-информации LGWR превышают возможности копирования процесса ARCH. Оно также служит причиной возникновения ожидания контрольной точки — ARCH становится «узким местом» для завершения всех транзакций в системе.

Следующие техники могут использоваться для смягчения проблемы:

  • Чередование с малым размером сегмента — разместите Ваши архивные журнальные файлы на дисковом массиве с малым размером сегмента чередования для увеличения скорости обращения к файлам процессом ARCH.
  • Большее число оперативных журнальных файлов — создайте достаточное число оперативных журнальных файлов с тем, чтобы LGWR не смог заполнить все журнальные файлы до того как процесс ARCH закончил копировать.
  • Увеличение числа ARCH-процессов — используйте несколько ARCH-процессов.

Материал почерпнут, в основном, из следующих источников: http://www.oracle.com/global/ru/oramag/augsept2003/admin_fast.html http://citforum.ru/database/oracle/vldb/7.shtml

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

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

Zhmur Arthur
12 июня 2008 г. в 17:17

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

dbstalker
12 июня 2008 г. в 17:26

Вы, конечно же , правы. Но я знаю наверняка, что еще до сих пор успешно експлуатируются версии ORACLE<=8 на небольших серверах.

denix1
2 января 2009 г. в 10:03

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

 

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

Я не спамер: введите суму 4+1



 

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

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

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

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


 
 

Бизнес форум

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

Печь булерьян в дом
21 сентября, 1 ответа
Как Открыть Футбольную Школу
20 сентября, 1 ответа
IP телефония
20 сентября, 1 ответа