Online redo logs или Событие контрольной точки в Oracle

Online redo logs или Событие контрольной точки в Oracle

Итак. Когда приложение запрашивает данные, база складывает их в буферный кэш — область памяти в SGA. Когда данные изменяются, база производит изменения не непосредственно в файле данных, а в буферном кэше. Одновременно в отдельную область памяти — redo log buffer — записывается информация, по которой, в случае необходимости, можно будет повторить произошедшее изменение. Когда изменение фиксируется (commit), оно, опять же, не сбрасывается сразу в файл данных, но информация из redo log buffer сбрасывается в online redo лог — специально для этого предназначенный файл. До тех пор, пока изменение не записано в файл данных, необходимо хранить информацию о нём где-то на диске на тот случай, если база упадёт. Если, к примеру, выключится питание сервера, то, само собой, все данные, хранящиеся в памяти, будут потеряны. В этом случае redo лог — это единственное место, где хранится информация о произошедшем изменении. После рестарта базы Oracle фактически повторит прошедшую транзакцию, вновь изменит нужные блоки и сделает commit. Поэтому до тех пор, пока информация из redo лога не будет сброшена в файл данных, повторно использовать этот redo лог невозможно.

Специальный фоновый процесс базы данных DBWn по мере необходимости освобождает буферный кэш, а также выполняет событие контрольной точки (checkpoint). Контрольная точка — это событие, во время которого «грязные» (изменённые) блоки записываются в файлы данных. За событие контрольной точки отвечает процесс CKPT (checkpoint process), который и пишет информацию о контрольной точке в control file (о том, что такое control file, в другой раз) и заголовки файлов данных.

Событие контрольной точки обеспечивает согласованность данных и быстрое восстановление базы. Восстановление данных ускоряется, т.к. все изменения до контрольной точки пишутся в файлы данных. Это избавляет от необходимости во время восстановления применять redo логи, сгенерированные до контрольной точки. Контрольная точка гарантирует, что все изменённые блоки в кэше действительно записаны в соответствующие файлы данных.

  • Потоковые контрольные точки (thread checkpoins). В файл данных пишутся подряд все изменения, произошедшие в рамках определённого экземпляра до определённого момента. Случаются они в следующих ситуациях:
    • полная остановка базы;
    • alter system checkpoint;
    • переключение online redo лога;
    • alter database begin backup.
    • FAST_START_MTTR_TARGET (сколько времени в секундах займёт восстановление базы после сбоя; если я что-нибудь в чём-нибудь понимаю, то речь идёт о времени, которое потребуется для применения имеющихся в наличии online redo логов).
    • LOG_CHECKPOINT_INTERVAL (частота события контрольной точки — допустимое количество блоков файла online redo log, которые были заполнены после пердыдущей контрольной точки; блоки — это блоки в терминах операционной системы, а не базы данных).
    • LOG_CHECKPOINT_TIMEOUT (максимально допустимое количество секунд, между двумя событиями контрольной точки).
    • LOG_CHECKPOINTS_TO_ALERT (true/false; определяет, скидывать ли переключение контрольной точки в alert.log; полезная штука, лучше бы выставить в true).
    Заглянем теперь в нашу базу

    Как уже упоминалось, событие контрольной точки происходит при переключении online redo лога. Хорошей практикой, если верить металинку, считается переключение логов каждые двадцать минут. Слишком маленькие online redo логи могут увеличить частоту событий контрольной точки и снизить производительность. Oracle рекомендует, чтобы размер файлов online redo логов был одинаковым, а также чтобы существовало как минимум две группы логов для каждого экземпляра базы.

    Для отслеживания частоты переключения логов можно заглянуть в alert log. Пример переключения online redo логов.

    Иногда в alert.log можно обнаружить следующие ошибки.

    Это означает, что Oracle собирается повторно использовать online redo лог, данные из которого ещё не сброшены в файлы данных. В этом случае все операции в базе приостанавливаются (производительность приложения резко ухудшается), вызывается событие контрольной точки и «грязные» блоки срочно сбрасываются на диск. Если подобные ошибки возникают от случая к случаю, то, пожалуй, ничего катастрофического в этом нет. Однако, если они становятся постоянными, то пора полумать о том, чтобы изменить размер и количество redo логов.

    Из cookbook. Как изменить размер и/или количество online redo логов

    1. Для начала просто посмотрим на состояние логов.

    Попробуем увеличить размеры логов до 100M.

    2. Посмотрим непосредственно на файлы redo логов.

    3. Создадим три новых группы логов по 100M каждая.

    Посмотрим, что получилось

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

    Теперь с чистой совестью удаляем лишние логи

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

    После чего смело повторяем попытку.

    5. Проверим, всё ли у нас получилось.

    6. Сейчас самое время сделать бэкап базы. Так, на всякий случай.

    7. Теперь можно удалить лишние файлы операционной системы.

    Что делать, если у нас установлен Oracle RAC.

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

    Команда ALTER SYSTEM CHECKPOINT LOCAL работает только с экземпляром, с которым вы в данный момент соединены. Чтобы вызвать событие контрольной точки для всей базы, нужно вызвать ALTER SYSTEM CHECKPOINT или ALTER SYSTEM CHECKPOINT GLOBAL.

    Команда ALTER SYSTEM SWITCH LOGFILE влияет только на тот экземпляр, с которым вы в данный момент соединены. Чтобы переключить online redo логи для всей системы можно воспользоваться командой ALTER SYSTEM ARCHIVE LOG CURRENT.

    Создавать новые online redo логи придётся для каждого экземпляра в отдельности.

    Кстати, имя файла можно не указывать. База сама назовёт его в соответствии сосвоими представлениями о прекрасном.

    Ещё кстати. Можно файлы online redo логов размножить.

    Зачем размножить? Потому что, если по каким-то причинам файл online redo лога будет повреждён или потерян, то, имея его неповреждённую и непотерянную копию на другом диске, восстановление — дело двух минут. А вот если копии нет, то придётся повозиться (но процесс восстановления утерянных redo логов — уже совсем другая история).