Октябрь/Ноябрь 2003
Профессионалу администратору
Олег Летаев,
Lead Technical Analyst,
Oracle Certified Professional,
компания LEAVES (www.leaves.ru)
Быстрое восстановление при старте для Oracle9i
[От редакцииOM/RE: В предыдущем выпуске нашего журнала в статье “Быстрое восстановление при старте”
(/ru/oramag/augsept2003/admin_fast.html) по технической ошибке выпало авторское упоминание, что данная статья относится, прежде всего, к Oracle8i. Мы приносим свои извинения уважаемым читателям и весьма благодарны автору, О.Летаеву, который предложил нам опубликовать дополнение об изменениях, произошедших в механизмах быстрого восстановления в Oracle9i.]
|
Параметр инициализации
FAST_START_MTTR_TARGET
|
В Oracle9i появился новый параметр инициализации FAST_START_MTTR_TARGET, который призван заменить FAST_START_IO_TARGET. Новый параметр устанавливает желаемое максимальное время восстановления после сбоя экземпляра (MTTR – Mean Time To Recover). Желаемое время задается в секундах от 0 до 3600, причем значение 0 запрещает этот механизм.
Параметр FAST_START_MTTR_TARGET удобнее, поскольку позволяет устанавливать желаемое время восстановления, не пересчитывая его предварительно в операции ввода/вывода. Таким образом, время восстановления становится более предсказуемым.
Oracle сохраняет в контрольном файле статистическую информацию о предыдущих восстановлениях после сбоя экземпляра. Наличие такой “калибровочной” информации позволяет СУБД точнее рассчитывать зависимость времени восстановления от количества журнальных блоков, подлежащих накату, и количества “грязных” буферов в кэше. Благодаря этому, и фактическое время восстановления приближается к желаемому. Однако, чтобы накопить эту “калибровочную” информацию, нужно сымитировать несколько сбоев экземпляра во время активной работы и произвести восстановление. Таким образом, Oracle настроит свои формулы под характеристики конкретного сервера, его подсистемы ввода, вывода.
Заданное значение параметра инициализации FAST_START_MTTR_TARGET может быть расценено Oracle как недостижимо малое или недостижимо большое.
Например, вы установили FAST_START_MTTR_TARGET = 10. СУБД может рассчитать, что для обеспечения времени восстановления 10 сек, нужно поддерживать количество “грязных” буферов в кэше в пределах 50, а это невозможно, так как приведет к неудовлетворительной производительности.
И наоборот, вы установили FAST_START_MTTR_TARGET = 1500. СУБД может рассчитать, что, даже если все буфера в кэше будут “грязными”, накат завершится быстрее.
В обоих случаях значение параметра FAST_START_MTTR_TARGET не будет считаться ошибочным. Просто Oracle при работе будет использовать скорректированное значение MTTR, которое можно увидеть в одном из системных представлений, но об этом чуть ниже.
Установка всех упоминавшихся ранее параметров (FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL или LOG_CHECKPOINT_TIMEOUT) одновременно с FAST_START_MTTR_TARGET не рекомендуется, так как их значения будут интерферировать труднопредсказуемым образом, и время восстановления, в итоге, может существенно отличаться от ожидаемого.
Параметр инициализации DB_BLOCK_MAX_DIRTY_TARGET в Oracle9i объявлен устаревшим и удален. Таким образом, рассматриваемая функциональность более недоступна в Oracle Database Standard Edition.
|
Рекомендации для Oracle9i
|
Наилучшим решением для Oracle9i будет использование только одного параметра из всех перечисленных – FAST_START_MTTR_TARGET.
Информация о Fast-Start Checkpointing
|
Представление V$Instance_Recovery
|
Вследствие изменений в работе механизма Fast-Start Checkpointing изменилось и представление V$Instance_Recovery. Изменения практически не коснулись ранее существовавших столбцов, но добавились три новых столбца. Для удобства я решил повторить описание представления, изменения выделены курсивом.
|
Столбец |
Описание |
|
Recovery_Estimated_IOs |
Оценка количества операций ввода/вывода, которое потребуется выполнить при восстановлении, если сбой экземпляра произойдет сейчас. Имеет смысл, только если включен механизм FAST_START_IO_TARGET. |
|
Actual_Redo_Blks |
Фактическое количество блоков журнального файла, которое должно быть прочитано при восстановлении, если сбой экземпляра произойдет сейчас. |
|
Target_Redo_Blks |
Целевое (к которому Oracle стремится) количество блоков журнального файла, которое должно быть прочитано при восстановлении. Текущий (с учетом того, что два столбца динамические) минимум из последующих четырех столбцов. Это правило и позволяет “неявно скорректировать” LOG_CHECKPOINT_INTERVAL как отмечалось в
предыдущей статье в разделе "Недокументированная особенность" . |
|
Log_File_Size_Redo_Blks |
90% размера наименьшего журнального файла в блоках журнала. Фиксирован. |
|
Log_Chkpt_Timeout_Redo_Blks |
Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_TIMEOUT. Динамический. Увеличивается, если количеств журнальных блоков, записанных за LOG_CHECKPOINT_TIMEOUT секунд, растет (скорость записи в журнал растет), и уменьшается в противном случае вплоть до 0. |
|
Log_Chkpt_Interval_Redo_Blks |
Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_INTERVAL. Фиксирован. Равен LOG_CHECKPOINT_INTERVAL. |
|
Fast_Start_IO_Target_Redo_Blks |
Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации FAST_START_IO_TARGET. Динамический. Растет, если отметка контрольной точки движется по другой причине (LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT). Мало изменяется, если отметку контрольной точки двигает сам параметр FAST_START_IO_TARGET.
В Oracle9i считается устаревшим, всегда имеет значение NULL и поддерживается только в целях совместимости. |
|
Target_MTTR |
Добавлен в Oracle9i. Целевое значение MTTR. Может не совпадать со значением FAST_START_MTTR_TARGET, если значение этого параметра недостижимо велико или мало, а также если установлены другие параметры инициализации, влияющие на время восстановления. Если FAST_START_MTTR_TARGET отключен, в этом столбце – 0. |
|
Estimated_MTTR |
Добавлен в Oracle9i. Текущая оценка времени восстановления. |
|
CKPT_Block_Writes |
Добавлен в Oracle9i. Суммарное количество блоков данных, записанных при отработке инкрементальных контрольных точек. Равняется разности статистик physical writes и physical writes non checkpoint. |
Фактически, при использовании механизма MTTR Oracle9i смысл имеют только последние 3 столбца.
|
Представление V$MTTR_Target_Advice
|
В Oracle9i добавлено представление V$MTTR_Target_Advice, которое позволяет оценить зависимость количества операций записи из буферного кэша на диск от значения параметра инициализации FAST_START_MTTR_TARGET.
Это представление может подсказать, например, что при увеличении FAST_START_MTTR_TARGET на 25% количество операций записи из буферного кэша уменьшится на 25%, а при уменьшении FAST_START_MTTR_TARGET на 25% количество операций записи из буферного кэша увеличится на 50%. Таким образом, представление V$MTTR_Target_Advice помогает найти компромисс между производительностью СУБД и временем восстановления.
Количество операций записи из буферного кэша на диск рассчитывается для 5 значений MTTR: 0.1, 0.5, 1, 1.5 и 2, где за 1 берется текущее значение FAST_START_MTTR_TARGET. Таким образом, представление обычно содержит 5 записей, но может содержать и меньше, если, например, значение 0.5FAST_START_MTTR_TARGET получается недостижимо мало или 1.5FAST_START_MTTR_TARGET недостижимо велико.
Представление V$MTTR_Target_Advice включает следующие столбцы:
|
Столбец |
Описание |
|
MTTR_Target_For_Estimate |
MTTR в секундах, соответствующий 0.1, 0.5, 1, 1.5 и 2 от текущего FAST_START_MTTR_TARGET. |
|
Advice_Status |
Состояние сбора статистики по MTTR (включено/выключено) |
|
Dirty_Limit |
Оценка максимального количества “грязных” буферов в кэше, при котором можно уложиться в рассматриваемый MTTR. |
|
Estd_Cache_Writes |
Оценка количества операций записи из буферного кэша на диск при рассматриваемом MTTR. |
|
Estd_Cache_Write_Factor |
Отношение количества операций записи из буферного кэша при рассматриваемом MTTR к количеству операций записи из буферного кэша при текущем MTTR. |
|
Estd_Total_Writes |
Оценка общего количества операций записи на диск при рассматриваемом MTTR. |
|
Estd_Total_Write_Factor |
Отношение общего количества операций записи при рассматриваемом MTTR к общему количеству операций записи при текущем MTTR. |
|
Estd_Total_IOs |
Оценка общего количества операций ввода/вывода при рассматриваемом MTTR. |
|
Estd_Total_IO_Factor |
Отношение общего количества операций ввода/вывода при рассматриваемом MTTR к общему количеству операций ввода/вывода при текущем MTTR. |
Пример.
Я установил FAST_START_MTTR_TARGET на новой БД в отсутствие “калибровочной” информации в значение 60. Oracle счел, что выполнить накат за 60 сек нереально (для этого придется поддерживать слишком малое количество “грязных” буферов), минимум – 71 сек. Поэтому мы видим в представлении всего 3 записи: для 1FAST_START_MTTR_TARGET, 1.5 и 2.
Я также привел только несколько столбцов, достаточных для иллюстрации принципов работы представления.
MTTR_TARGET_FOR_ESTIMATE DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR
------------------------ ----------- ----------------- -----------------------
71 1000 6637 1
90 1491 5249 0.7909
120 2287 4434 0.6681
По данным представления V$MTTR_Target_Advice при увеличении FAST_START_MTTR_TARGET в 1.5 раза объем записи по инкрементальным контрольным точкам сократится на 20%, а при увеличении в 2 раза – на 33%.
Сбор статистики по MTTR включается при соблюдении двух условий:
- параметр инициализации FAST_START_MTTR_TARGET включен (не 0)
- параметр инициализации STATISTICS_LEVEL имеет значение All или Typical.
Если сбор статистики по MTTR отключен, представление V$MTTR_Target_Advice будет содержать статистическую информацию, собранную в последний раз, когда сбор статистики был включен. Если сбор статистики не был включен с момента старта экземпляра, представление будет пустым.
Если значение параметра FAST_START_MTTR_TARGET динамически изменено во время сбора статистики, сбор статистики временно приостанавливается до вступления в силу нового значения параметра. В этот период времени представление V$MTTR_Target_Advice сохраняет информацию для прежнего значения FAST_START_MTTR_TARGET.
Оптимизированное восстановление массовых операций
При выполнении массовых (bulk) операций Oracle записывает данные непосредственно на диск, минуя буферный кэш. При этом:
- гарантируется, что измененные данные будут записаны на диск до фиксации транзакции;
- появляется, как следствие, возможность опустить фазу наката из журнальных файлов при восстановлении (на самом деле, даже сама журнализация массовой операции может быть отключена – режим NOLOGGING, т.е. данных для наката в журнальном файле и не будет);
- данные пишутся только в ранее не использовавшиеся блоки данных;
- откат, как следствие, сводится к тому, чтобы пометить затронутые блоки данных, как ранее не использовавшиеся.
|
