oracle redo log что это
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 логи, сгенерированные до контрольной точки. Контрольная точка гарантирует, что все изменённые блоки в кэше действительно записаны в соответствующие файлы данных.
Заглянем теперь в нашу базу
Как уже упоминалось, событие контрольной точки происходит при переключении 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 логов — уже совсем другая история).
Управление онлайновыми журналами Oracle Redo logs
Андрей Волков
Системное, сетевое администрирование +DBA. И немного программист!)) Профиль автора.
Онлайновые журналы повторного выполнения (redo logs) — это средства Oracle, благодаря которым гарантируется, что все изменения, проведенные пользователями, будут зафиксированы в журналах на случай, если произойдет сбой между моментом проведения изменений и моментом записи их в постоянное хранилище. Таким образом, журналы повторного выполнения — основа процесса восстановления.
Oracle организует свои файлы журналов повторного выполнения в группы журналов, и нужно иметь как минимум две разных группы журналов повторного выполнения и, минимум, по одному члену в каждом. Потребуется, самое меньшее, две группы, потому что когда один журнал повторного выполнения архивируется, процесс писатель журнала должен иметь возможность продолжать писать в активный журнал повторного выполнения.
Хотя база данных Oracle будет достаточно хорошо работать и с только одним членом в каждой группе журналов повторного выполнения, в Oracle настоятельно рекомендуют мультиплексировать онлайновые журналы повторного выполнения. Мультиплексирование означает просто то, что необходимо поддерживать более одного члена в каждой из групп журналов повторного выполнения. Все члены такой группы идентичны — мультиплексирование предназначено для защиты от потери одной из копий файла журнала. При мультиплексировании онлайновых журналов повторного выполнения процесс-писатель журналов выполняет запись параллельно во все файлы члены группы.
Совет. Всегда мультиплексируйте онлайновый журнал повторного выполнения, поскольку вы можете потерять данные, если случится сбой в онлайновом журнале повторного выполнения из-за проблем с диском. Мультиплексированные журналы повторного выполнения в идеале должны располагаться на разных дисковых приводах под управлением разных дисковых контроллеров.
Сравнение аппаратного зеркального отображения и мультиплексирования Oracle
Зеркальное отображение защитит данные от дисковых сбоев, но не защитит от непреднамеренного удаления файлов. Мультиплексирование гарантирует защиту файлов от подобного рода ошибок.
Если вы потеряете онлайновый журнал повторного выполнения, то можете утратить важные данные, поэтому при мультиплексированной системе журналов повторного выполнения фоновый процесс LGWR, который отвечает за запись данных из буфера журнала повторного выполнения, пишет одновременно во все (идентичные) файлы-члены мультиплексированной группы. Если возникнут проблемы записи в один из членов мультиплексированной группы журналов повторного выполнения, запись в другие члены группы пройдет беспрепятственно.
Группы онлайнового журнала повторного выполнения
В случае мультиплексирования журнала повторного выполнения поддерживаются идентичные копии одних и тех же файлов. Предположим, что вы создаете две копии файла журнала повторного выполнения. Понадобится создать группу журналов повторного выполнения, которая будет включать эти два идентичных файла, именуемых членами группы. В любой заданный момент времени процесс LGWR будет писать в одну группу файлов онлайнового журнала повторного выполнения, и члены этой группы будут называться текущими.
Ниже описаны некоторые базовые условия для групп журнала повторного выполнения Oracle.
Создание групп онлайнового журнала повторного выполнения
Добавление групп журнала повторного выполнения
Хотя необходимо иметь минимум две группы онлайнового журнала повторного выполнения, идеальное количество таких групп для базы данных зависит только от интенсивности транзакций.
Совет. Начните с трех групп онлайнового журнала повторного выполнения и следите за журналом предупреждающих сигналов на предмет появления в нем любых ошибок журнала повторного выполнения. Если журнал сигналов часто показывает ожидание процесса-писателя журналов возможности записи в журнал, значит, следует увеличить количество групп журнала повторного выполнения.
Следующий оператор, который использует синтаксис ADD LOGFILE GROUP, добавляет новую группу журнала повторного выполнения в базу данных. Обратите внимание, что эта группа дублирована; в ней создается два файла журнала повторного выполнения, а не один:
В примере из предыдущего раздела были созданы три группы онлайнового журнала повторного выполнения, но каждая из них включала только по одному члену. Чтобы продублировать эти группы с целью повышения безопасности, потребуется добавить по одному члену в каждую группу. Для добавления одного члена в существующую группу используется оператор ADD LOGFILE MEMBER:
Как видите, размер нового члена группы журнала повторного выполнения, добавляемого в группу 2, специфицировать не понадобилось. Размер нового члена будет просто установлен равным размерам существующих членов группы.
Переименование файлов журнала повторного выполнения
Для переименования файла журнала повторного выполнения выполните следующие шаги.
Удаление онлайновых журналов повторного выполнения
С помощью следующей команды можно уничтожить всю группу журнала повторного выполнения:
Для удаления единственного члена группы служит такая команда:
Если файл онлайнового журнала повторного выполнения, который планируется удалить, активен или является текущим, Oracle не позволит это сделать. В этом случае сначала нужно с помощью следующей команды переключить файл журнала, после чего можно будет удалить его:
Повреждение онлайнового журнала повторного выполнения
Включение параметра инициализации DB_BLOCK_CHECKSUM гарантирует проверку Oracle журналов повторного выполнения перед их архивированием. Если онлайновые журналы повторного выполнения повреждены, файл не может быть архивирован, и единственным решением может быть лишь их удаление и воссоздание заново. Но если есть только две группы журналов, вы не сможете этого сделать, поскольку Oracle требует постоянного наличия минимум двух групп файлов онлайновых журналов повторного выполнения. В этом случае можно создать новую (третью) группу журнала повторного выполнения и удалить текущую.
Также не удастся удалить файл онлайнового журнала повторного выполнения, если этот файл является частью текущей группы. В этом случае стратегия должна состоять в повторной инициализации файла журнала с помощью следующей команды:
Если группы журналов еще не были архивированы, можно применить следующий оператор:
Мониторинг журналов повторного выполнения
Для мониторинга журналов повторного выполнения применяются два ключевых динамических представления — V$LOG и V$LOGFILE.
Представление V$LOGFILE содержит полные имена файлов журналов повторного выполнения, их состояние и тип, как показано ниже:
Представление V$LOG выдает детальную информацию о размерах и состоянии журналов повторного выполнения, а также показывает, были ли журналы архивированы:
sidadm
записки SAP Basis консультанта
Полезное
вторник, 23 июня 2020 г.
Базовые механизмы СУБД Oracle: Redo Logs и Undo Segments
Поэтому этот пост прошу воспринимать не как попытку показать какой я умный, а как попытку упорядочить картину прежде всего у себя в голове. Знаете же выражение: пока объяснял, сам понял. 🙂
Как вы скорее всего уже знаете, при использовании базы данных Oracle в SAP системах в качестве клиентов базы данных выступают рабочие процессы SAP инстанций ( SAP WPs ). Каждому такому процессу соответствует один рабочий процесс со стороны инстанции Oracle ( shadow process ).
Использование механизма отложенной записи повышает быстродействие. Во-первых, во многих случаях, прежде чем DBW0 скопирует блок на диск, данные в блоке могут несколько раз измениться. Во-вторых, повышается эффективность операций ввода-вывода, так как DBW0 часто выполняет запись сразу нескольких блоков параллельно.
Почти всегда можно руководствоваться правилом: чем больше данный кэш, тем быстрее работает база данных. Вспомните мой старый пост про это.
Redo-записи содержат информацию необходимую и достаточную для того, чтобы реконструировать, восстановить или откатить, внесенные в базу данных с помощью SQL-запросов данные прежде всего в подтверждённых (commit) транзакциях.
Так как количество Online redo log files также заранее ограничено, Oracle перезаписывает старые Redo-записи новыми, используя эти файлы по кругу.
Новые значения модифицированных данных, которые хранятся в Redo-записях, называются «after images».
Теперь основываясь на всех механизмах, которые были описаны выше, разберём как происходит восстановление базы данных.
Речь пойдёт не о восстановлении из резервной копии базы данных, которую должен выполнять администратор. А речь пойдёт об автоматическом восстановлении базы данных, которое СУБД производит в момент старта. Так называемое instance recovery. Оно необходимо, если предыдущий останов базы данных был выполнен не чисто, например, с опцией IMMEDIATE или ABORT. Или произошёл сбой работы сервера базы данных по аппаратной или программной причине.
База данных Oracle Database для начинающих: основы базы данных
Илья Дергунов
Автор статьи. ИТ-специалист с 20 летним стажем, автор большого количества публикаций на профильную тематику (разработка ПО, администрирование, новостные заметки). Подробнее.
Довольно часто случается такая неприятность, что в alert.log базы одно за другим сыпятся сообщения типа «Checkpoint not complete». Стандартный совет в этом случае: «увеличьте количество и/или размер redo логов». А дальше вопрос, кто такие эти redo логи и с чем их едят.
Теоретические аспекты
Итак, когда приложение запрашивает данные, база складывает их в буферный кэш — область памяти в SGA. Когда данные изменяются, база производит изменения не непосредственно в файле данных, а в буферном кэше. Одновременно в отдельную область памяти — redo log buffer — записывается информация, по которой, в случае необходимости, можно будет повторить произошедшее изменение. Когда изменение фиксируется (commit), оно, опять же, не сбрасывается сразу в файл данных, но информация из redo log buffer сбрасывается в online redo log — специально для этого предназначенный файл. До тех пор, пока изменение не записано в файл данных, необходимо хранить информацию о нём где-то на диске на тот случай, если база упадёт. Если, к примеру, выключится питание сервера, то, само собой, все данные, хранящиеся в памяти, будут потеряны. В этом случае redo logs — это единственное место, где хранится информация о произошедшем изменении. После рестарта базы Oracle фактически повторит прошедшую транзакцию, вновь изменит нужные блоки и сделает commit. Поэтому до тех пор, пока информация из redo лога не будет сброшена в файл данных, повторно использовать этот redo лог невозможно.
Специальный фоновый процесс базы данных DBWn по мере необходимости освобождает буферный кэш, а также выполняет событие контрольной точки (checkpoint). Контрольная точка — это событие, во время которого «грязные» (изменённые) блоки записываются в файлы данных. За событие контрольной точки отвечает процесс CKPT (checkpoint process), который и пишет информацию о контрольной точке в control file (о том, что такое control file, в другой раз) и заголовки файлов данных.
Событие контрольной точки обеспечивает согласованность данных и быстрое восстановление базы. Восстановление данных ускоряется, т.к. все изменения до контрольной точки пишутся в файлы данных. Это избавляет от необходимости во время восстановления применять redo логи, сгенерированные до контрольной точки. Контрольная точка гарантирует, что все изменённые блоки в кэше действительно записаны в соответствующие файлы данных.
Виды контрольных точек (CKPT)
Частые события контрольной точки обеспечивают более быстрое восстановление после сбоев, но могут вызвать ухудшение производительности. В зависимости от количества файлов данных в системе, событие контрольной точки может быть достаточно ресурсоёмкой операцией, т.к. в этот момент все заголовки всех файлов данных становятся недоступны.
Параметры, от которых зависит частота событий контрольной точки и которые при желании можно настраивать:
Имеет смысл уточнить, что параметры FAST_START_MTTR_TARGET и LOG_CHECKPOINT_INTERVAL, если верить документации, являются взаимоисключающими.
Что происходит в базе данных Oracle при переключении логов?
Как уже упоминалось, событие контрольной точки происходит при переключении online redo лога. Хорошей практикой, если верить металинку, считается переключение логов каждые двадцать минут. Слишком маленькие online redo логи могут увеличить частоту событий контрольной точки и снизить производительность. Oracle рекомендует, чтобы размер файлов online redo логов был одинаковым, а также чтобы существовало как минимум две группы логов для каждого экземпляра базы.
Для отслеживания частоты переключения логов можно заглянуть в alert log.
Пример переключения online redo логов
Иногда в alert.log можно обнаружить следующие ошибки.
Это означает, что Oracle собирается повторно использовать online redo лог, данные из которого ещё не сброшены в файлы данных. В этом случае все операции в базе приостанавливаются (производительность приложения резко ухудшается), вызывается событие контрольной точки и «грязные» блоки срочно сбрасываются на диск. Если подобные ошибки возникают от случая к случаю, то, пожалуй, ничего катастрофического в этом нет. Однако, если они становятся постоянными, то пора подумать о том, чтобы изменить размер и количество redo логов.
Как изменить размер и/или количество online redo логов
1. Для начала просто посмотрим на состояние логов.
Попробуем увеличить размеры логов до 100M.
2. Посмотрим непосредственно на файлы redo логов.
3. Создадим три новых группы логов по 100M каждая.
Посмотрим, что получилось
4. Теперь можно удалить старые (слишком маленькие) логи. Для этого нужно, чтобы активным был лог из вновь созданных групп. Если в имеющейся ситуации это не так, то можно воспользоваться командой
Теперь с чистой совестью удаляем лишние логи
При удалении последнего лога как раз случилась ситуация, когда удалить лог невозможно, т.к. данные из него ещё не сброшены в файлы данных. Сделать это принудительно можно командой
После чего смело повторяем попытку.
5. Проверим, всё ли у нас получилось.
6. Сейчас самое время сделать бэкап базы. Так, на всякий случай.
7. Теперь можно удалить лишние файлы операционной системы.
Что делать, если у нас установлен Oracle RAC
В принципе, всё то же самое. С учётом того, что для каждого экземпляра существует свой отдельный набор redo логов и оперировать ими придётся по-отдельности.
Создавать новые online redo логи придётся для каждого экземпляра в отдельности.
Кстати, имя файла можно не указывать. База сама назовёт его в соответствии со своими представлениями о прекрасном.
Ещё кстати. Можно файлы online redo логов размножить.
Зачем размножить? Потому что, если по каким-то причинам файл online redo лога будет повреждён или потерян, то, имея его неповреждённую и непотерянную копию на другом диске, восстановление — дело двух минут. А вот если копии нет, то придётся повозиться (но процесс восстановления утерянных redo логов — уже совсем другая история).
Файлы базы данных Oracle
Предполагается, что вы инсталлировали базу данных, согласно документа.
Обязательные файлы:
Необязательные файлы:
Файлы данных (Data Files)
В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.
У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.
Данные в файлы вносятся исключительно средствами Oracle.
Следующий запрос, покажет, где находятся файлы данных.
Оперативные файлы журналов повтора (Online Redo Log Files)
Каждая база данных должна иметь не менее двух оперативных файлов журналов повтора. Текущий файл постепенно заполняется, после его заполнения (или переключения некоторыми командами), база данных приступает к записи в следующий файл. Эта операция называется переключением журналов.
Поскольку файлы повтора необходимы для выполнения восстановления базы данных и являются критичными, их объединяют в группы. Запись происходит одновременно в файлы одной группы.
Управляющие файлы (Control Files)
Поскольку база данных Oracle является физическим набором связанных файлов данных, то для их синхронизации и контроля требуется особые методы. Для этих целей используются управляющие файлы.
База данных Oracle может иметь один или несколько управляющих файлов. Если имеется несколько управляющих файлов, все они должны быть абсолютно идентичными. При каждом запуске базы данных Oracle читает информацию управляющего файла, а при каждом изменении размещения или добавления новых файлов данных и журналов базы данных обновляет управляющий файл.
Файлы параметров pfile, spfie (Parameter Files)
Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.
При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.
Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.
Как я могу узнать, что моя база данных использует PFILE или SPFILE?
Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:
Архивные файлы журналов повтора (Archive Log Files)
Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.
Если необходимо сохранить историю изменений, нужно, чтобы после переключения журналов сохранялась их копия. Для этого достаточно перевести работу базы данных в режим работы ARCHIVELOG.
Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно. Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных. А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.
Alert log и трассировочные файлы (trace file)
Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.
Файлы паролей (Password File)
Необязательный файл, используется для защиты информации о подключениях привилегированных пользователей. Если отсутствует, то вы можете выполнять администрирование своей базы данных, только локально. Кроме того, с его помощью контролируется количество привилегированных подключений для управления в одно и то же время.
Tags: Oracle Database, Файлы базы данных Oracle,
Oracle DBA
Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.
Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.