Размер журнального файла

Оптимальный размер журнального файла в системе зависит от объема генерируемой redoинформации и требований к продолжительности восстановления инстанции. Для расчета правильного интервала между контрольными точками и размера журнального файла для Вашей системы используйте следующий метод:

Определите требования к времени восстановления после краха. Обозначим это время, заданное в секундах, как t.

Рассчитайте скорость, с которой система применяет redo-информацию при восстановлении инстанции. Обозначим эту скорость, заданную в байтах в секунду, как r.

Установите значение параметра log_checkpoint_interval в r × t/b, где b — размер блока ввода/вывода в байтах в Вашей операционной системе.

Создайте журнальные файлы размером f = k × r × t, для некоторого целого k (т.е. f кратно r × t).

Если новые контрольные точки накапливаются без завершения предыдущих, то Вы должны увеличить значение log_checkpoint_interval. Вы можете определить частоту возникновения таких ситуаций сравнив значения статистик background_checkpoints_started и background_checkpoints_completed из v$sysstat. Если значения отличаются более чем на 1, значит контрольные точки не завершались к тому моменту, когда начинались новые.

Установите log_buffer в l = 3×n×s, где n — число дисков в массиве, хранящем журнальные файлы и s — размер сегмента чередования массива в байтах. Наибольший размер операции записи, генерируемый LGWR, будет примерно равен l/3 = n × s .

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

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

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

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

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

Содержание раздела