Профессионалу администратору

Олег Летаев,
Lead Technical Analyst,
Oracle Certified Professional,
компания LEAVES (www.leaves.ru)

Быстрое восстановление при старте

Источник: сайт компании LEAVES (www.leaves.ru), фрагмент материала О.Летаева “Возможности Oracle по обеспечению отказоустойчивости”, http://www.leaves.ru/rus/papers/Oracle%20Availability%20Options.pdf

Fast-Start Checkpointing

В Oracle8 коренным образом был переработан механизм выполнения контрольных точек: на смену интервальным контрольным точкам пришли инкрементальные контрольные точки.

При использовании инкрементальных контрольных точек Oracle (процессы DBWn) записывает блоки данных из кэша на диск не в произвольном порядке, а в порядке их модификации. Таким образом, файлы данных “движутся” во времени последовательно, поступательно, плавно, а не скачками, как при традиционном механизме контрольных точек (называемом теперь . механизмом интервальных контрольных точек). Кроме того, исключаются периодические спады производительности, вызванные массовой записью, характерные для традиционного механизма контрольных точек.

Параметры инициализации FAST_START_IO_ TARGET    и DB_BLOCK_MAX_ DIRTY_TARGET

Параметром инициализации FAST_START_IO_TARGET ограничивается максимальное число операций ввода/вывода, которое будет выполняться при накате из журнальных файлов во время восстановления экземпляра, т.е., фактически, максимальное время восстановления. Oracle автоматически корректирует интенсивность записи “грязных” блоков, чтобы удержаться в пределах установленного ограничения. Чем меньше значение этого параметра, тем быстрее пройдёт восстановление, но тем больше дополнительных операций записи будет выполняться при нормальной работе СУБД.

Значение параметра не может быть меньше 1000. Установка параметра в значение 0 запрещает механизм инкрементальных контрольных точек.

Для Oracle Database Standard Edition вместо FAST_START_IO_TARGET используется параметр инициализации DB_BLOCK_MAX_DIRTY_TARGET, который ограничивает количество “грязных” буферов в кэше. Чем меньше значение этого параметра, тем меньше будет “грязных” буферов в кэше, тем быстрее пройдёт восстановление, но тем больше дополнительных операций записи будет выполняться при нормальной работе СУБД. Таким образом, это параметр косвенно служит той же цели . ограничению времени восстановления экземпляра, . но параметр FAST_START_IO_TARGET действует точнее, так например DB_BLOCK_MAX_DIRTY_TARGET не гарантирует записи самых старых “грязных” буферов. Установка параметра в значение 0 также запрещает этот механизм.

Параметры инициализации LOG_CHECKPOINT _INTERVAL    и LOG_CHECKPOINT _TIMEOUT

Интерпретация параметров инициализации LOG_CHECKPOINT_INTERVAL и LOG_CHECKPOINT_TIMEOUT, ранее управлявших механизмом интервальных контрольных точек, также изменилась. Первый параметр устанавливает максимальный промежуток между позицией инкрементальной контрольной точки в журнальном файле и “хвостом” журнального файла в блоках журнала. Тем самым гарантируется, что при восстановлении экземпляра будет прочитано не более LOG_CHECKPOINT_INTERVAL блоков журнала. Второй параметр устанавливает максимальный промежуток между позицией инкрементальной контрольной точки в журнальном файле и текущим временем в секундах. Другими словами, инкрементальная точка должна указывать на позицию журнального файла, которая была записана LOG_CHECKPOINT_TIMEOUT секунд назад. Тем самым гарантируется, что ни один буфер в кэше не останется “грязным” на более чем LOG_CHECKPOINT_TIMEOUT секунд. Значение 0 в обоих случаях запрещает соответствующие механизмы контроля, т.е. отменяет соответствующие ограничения.

Недокументированная особенность

Параметр инициализации LOG_CHECKPOINT_INTERVAL имеет недокументированную особенность: Oracle неявно корректирует его так, чтобы он не превосходил 90% размера наименьшего журнального файла. Таким образом, когда подходит время для переключения журнала, позиция контрольной точки уже находится в заканчивающемся журнальном файле, и предыдущий журнальный файл уже свободен. Следовательно, даже при минимальном количестве журнальных групп (2) переключение журнала пройдёт без задержек, и ошибки “checkpoint not completed” исключаются. Фактически при выполнении контрольной точки по переключению журнала не делается ничего, никаких операций записи. Контрольная точка по переключению журнала отмечается как завершённая (в alert-файле) после того, как отметка контрольной точки выйдет за пределы заполненного журнального файла вследствие любых других причин, например, параметров инициализации LOG_CHECKPOINT_INTERVAL или LOG_CHECKPOINT_TIMEOUT. Таким образом, большое время между отметками о начале и окончании контрольной точки в alert-файле больше не должно вызывать беспокойства.

Проиллюстрируем на примере. Предположим, имеется два журнальных файла A и B одинакового размера. Когда журнальный файл B оказывается заполненным, позиция контрольной точки уже находится внутри него, не менее чем в 10% от его начала. Таким образом, журнальный файл A свободен и переключиться на него можно без задержек. Когда позиция контрольной точки, последовательно, постепенно продвигаясь, “выйдет” из журнального файла B, в alert-файле появится запись о том, что контрольная точка по переключению журнала завершена.

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

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

Наилучшим сочетанием, пожалуй, является использование FAST_START_IO_TARGET, который позволит сохранить постоянное время восстановления независимо от интенсивности транзакций в момент сбоя, и установка LOG_CHECKPOINT_TIMEOUT в достаточно большое значение (например, значение по умолчанию для Oracle Database Enterprise Edition . 30 мин или значение по умолчанию Oracle Database Standard Edition . 15 мин), что позволит продвинуть отметку контрольной точки вплоть до “хвоста” журнального файла в периоды низкой активности БД.

Информация о Fast-Start Checkpointing

Информация о работе механизма Fast-Start Checkpointing доступна через представление V$Instance_Recovery. Это представление содержит одну запись, включающую следующие столбцы:

Столбец	Описание
Log_Chkpt_Timeout_Redo_Blks	Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_TIMEOUT. Динамический. Увеличивается, если количеств журнальных блоков, записанных за LOG_CHECKPOINT_TIMEOUT секунд, растёт (скорость записи в журнал растёт), и уменьшается в противном случае вплоть до 0.
Log_Chkpt_Interval_Redo_Blks	Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_INTERVAL. Фиксирован. Равен LOG_CHECKPOINT_INTERVAL.
Log_File_Size_Redo_Blks	90% размера наименьшего журнального файла в блоках журнала. Фиксирован.
Fast_Start_IO_Target_Redo_Blks	Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации FAST_START_IO_TARGET. Динамический. Растёт, если отметка контрольной точки движется по другой причине (LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT). Приблизительно фиксируется, если отметку контрольной точки двигает сам параметр FAST_START_IO_TARGET.
Target_Redo_Blks	Целевое (к которому Oracle стремится) количество блоков журнального файла, которое должно быть прочитано при восстановлении. Текущий (с учётом того, что два столбца динамические) минимум из предыдущих четырёх столбцов. Это правило и позволяет “неявно скорректировать” LOG_CHECKPOINT_INTERVAL как отмечалось в Недокументированная особенность.
Actual_Redo_Blks	Фактическое количество блоков журнального файла, которое должно быть прочитано при восстановлении, если сбой экземпляра произойдёт сейчас.
Recovery_Estimated_IOs	Оценка количества операций ввода/вывода, которое потребуется выполнить при восстановлении, если сбой экземпляра произойдёт сейчас. Имеет смысл, только если включён механизм FAST_START_IO_TARGET.

В некоторых случаях (сразу после старта экземпляра, или если соответствующий механизм отключен установкой параметра инициализации в 0) столбцы V$Instance_Recovery могут содержать значение 232-1. Это значение должно быть проигнорировано.

Fast-Start Parallel Rollback

Oracle обеспечивает открытие БД и начало выполнения новых транзакций сразу после завершения фазы наката при восстановлении, т.е. при наличии в БД незавершённых транзакций, подлежащих откату.

Откат незавершённой транзакции будет выполняться той сессией (серверным процессом), которой понадобятся данные, заблокированные этой незавершённой транзакцией. Причём откатываться будут только эти данные, а не вся транзакция целиком.

Остальные незавершённые транзакции (части незавершённых транзакций) откатываются в фоновом режиме параллельными процессами SMON, количество которых определяется параметром инициализации FAST_START_PARALLEL_ROLLBACK.

Этот параметр может иметь значения LOW (количество процессов не более 2*CPU_COUNT), HIGH (количество процессов не более 4*CPU_COUNT) и FALSE (параллельный откат запрещён).

При наличии OPS откат может проводиться параллельно несколькими узлами кластера.

Информация о Fast-Start Parallel Rollback

Информация о ходе Fast-Start Parallel Rollback доступна через следующие представления:

• V$Fast_Start_Servers содержит информацию о параллельных процессах SMON и об объёме работы, выполненном каждым процессом
• V$Fast_Start_Transactions позволяет проследить ход параллельного отката на уровне отдельных транзакций.