Archivelog oracle что это

Обновлено: 06.07.2024

Защита Вашего Избыточного Набора

Последний бэкап контрольного файла и всех файлов данных
Все архивные журналы изменений, сгенерированные после того, как был взят этот последний бэкап данных
Дубликаты текущего контрольного файла и файлы онлайн журналов изменений, сгенерированные посредством мультиплексирования БД Oracle, зеркалирования ОС или того и другого
Копии файлов конфигурации, таких как файл параметров сервера (англ. server parameter file или сокр. spfile), tnsnames.ora и listener.ora

Таким образом, минимальная база данных промышленного уровня требует по крайней мере два дисковых накопителя: один будет содержать файлы избыточного набора, а другой файлы БД. В идеале, отделите избыточный набор от основных файлов всеми возможными путями: разными томами, отдельными файловыми системами и отдельными устройствами RAID.

Мультиплексируйте файлы онлайн журнала транзакций (redo) и текущий контрольный файл на уровне базы данных. (Например, сконфигурируйте базу данных писать ее онлайн журналы в два или более местоположений, так, чтобы каждая операция записи выполнялась базой, а не на уровне ОС или избыточности на уровне оборудования.) Если Вы настроите мультиплексирование на уровне базы данных, то сбой ввода/вывода или сбой операции записи повредят только одну из копий.
В идеале, мультиплексированные файлы должны распологаться на разных дисках под управлением разных контроллеров дисков. Мгновенная область восстановления является отличным местом для одной из копий этих файлов.
Вы также можете зеркалировать онлайн журналы изменений и текущий контрольный файл на уровне ОС или на уровне оборудования, но это не замена для мультиплексирования на уровне БД.
При работе в режиме ARCHIVELOG архивируйте журналы транзакций в несколько местоположений, в идеале на разные диски. Если Вы используете мгновенную область восстановления, то одним из этих местоположений сделайте FRA.
Используйте зеркалирование контрольного файла посредством ОС или оборудования. Все копии контрольного файла, мультиплексированные на уровне БД, должны быть все время доступны, иначе произойдет сбой экземпляра. Если Вы используете зеркалирование контрольного файла средствами ОС или оборудования, ваша база данных может продолжать работать даже в случае, если одна из копий контрольного файла, зеркалированного на уровне ОС, не доступна из-за выхода из строя диска.
Используйте зеркалирование средствами ОС или оборудования для основных файлов данных, если это возможно, чтобы избежать выполнения восстановления носителя для простых случаев дисковых сбоев.
Храните по крайне мере одну копию полного избыточного набора—включая самый последний бэкап базы—на диске. Мгновенная область восстановления является идеальным местом для избыточного набора.
Если целевая база данных хранится на RAID устройстве, то следует хранить избыточный набор на группе дисков, которые не входят в то же самое RAID устройство.
Если Вы храните избыточный набор на ленте, то поддерживайте по крайней мере две копии данных, чтобы защититься от риска сбоя ленты. Кроме того, если у Вас есть более одного бэкапа одних и тех же данных, то рассмотрите возможность сохранения бэкапов данных в различные моменты времени. Таким образом, если один из бэкапов или разделенное зеркало было создано, когда БД уже повреждена, то у Вас по-прежнему будет бэкап, взятый, когда база данных еще была целой.

Решение об Использовании Мгновенной Области Восстановления (FRA)

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

Некоторые возможности бэкапа и восстановления БД Oracle, такие как Ретроспективная База Данных Oracle и гарантированные точки реставрации, требуют использования FRA в обязательном порядке. Однако, использование мгновенной области восстановления для этих возможностей не заставляет Вас применять ее для хранения всех файлов, связанных с восстановлением.

Однако, даже когда ее использование не обязательно, мгновенная область восстановления предлагает ряд преимуществ по сравнению с другими способами хранения бэкапов на диске. Бэкапы, перемещаемые из FRA на ленту остаются также и на диске до тех пор, пока хватает места для других требуемых файлов, уменьшая необходимость реставрации бэкапов с ленты. В то же время, устаревшие файлы, которые более не нужны для целей восстановления, а также файлы, резервно скопированные на ленту, становятся разрешенными к удалению и удаляются, когда потребуется место. Администратор (DBA) больше не должен вручную удалять старые бэкапы, и, таким образом, уменьшается вероятность того, что DBA случайно удалит файлы избыточного набора.

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

Выбор Между Режимами ARCHIVELOG и NOARCHIVELOG

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

Ваша база данных может работать в двух режимах: режим ARCHIVELOG или режим NOARCHIVELOG. В режиме ARCHIVELOG используемая группа онлайн журналов изменений должна быть скопирована в одно или более архивных местоположений, прежде чем она может быть повторно использована. Архивирование журнала изменений сохраняет все транзакции, хранимые в этом журнале, так что они могут использоваться в операциях восстановления позже. В режиме NOARCHIVELOG группы онлайн журналов изменений просто перезаписываются, когда журнал заполняется и начинает использоваться повторно. Вся информация о транзакциях, записанных в этой группе онлайн журналов транзакций теряется.

Последствия Работы в Режиме NOARCHIVELOG

Работа вашей базы данных в режиме NOARCHIVELOG накладывает серьезные ограничения на вашу стратегию бэкапа и восстановления.

Вы не можете выполнять бэкапы базы в режиме онлайн. Вы должны аккуратно остановить базу данных, прежде чем сможете взять бэкап в режиме NOARCHIVELOG.
Вы не можете использовать какие-либо методы восстановления данных, которые требуют архивных журналов транзакций. Сюда входят полное восстановление носителя и восстановление носителя на момент времени, о которых я рассказывал в восстановление на момент времени отдельных табличных пространств и Ретроспективная База Данных (в будущем я планирую подробнее рассказать об этих продвинутых возможностях).

Если Вы запускаете базу в режиме NOARCHIVELOG и должны восстановить ее после повреждения файлов данных из-за сбоя диска, Вы имеете две основных опции восстановления:

Сбросить все объекты, имеющие какие-либо экстенты, расположенные в подверженных воздействию сбоя файлах, и затем сбросить сами эти файлы. Оставшаяся часть базы данных останется нетронутой, но все данные в пораженных файлах будут потеряны. из наиболее позднего бэкапа и потерять все изменения в базе, сделанные с момента взятия этого бэкапа. (Восстановление изменений с момента взятия бэкапа потребовало бы выполнения восстановления носителя, которое использует архивные журналы транзакций.)

Последствия Работы в Режиме ARCHIVELOG

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

Когда требования производительности зашкаливают или ограничения дискового пространства очень суровые, может статься более предпочтительным работа в режиме NOARCHIVELOG , несмотря на ограничения, которые накладывает этот выбор на опции восстановления.

Решение об Использовании Ретроспективных Возможностей Оракл и Точек Реставрации

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

В режиме ARCHIVELOG восстановление возможно до момента последней зафиксированной транзакции. Большинством производственных баз данных управляют в режиме ARCHIVELOG.

Когда делаются модификации с данными в базе данных, данные о транзакциях записываются в онлайновый файл журнала транзакций. Данный файл определяется как записываемый в данный момент. Когда он заполняется, процесс Архиватора (ARCn) копирует онлайновый файл журнала в другое расположение, которое служит архивом этого файла и может храниться столько, сколько потребуется. Это обеспечивает больше возможностей для восстановления, потому что можно сохранять, резервировать и извлекать из резервных копий все архивные журналы транзакций, когда-либо сгенерированные.

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

Конфигурирование Режима ARCHIVELOG

Чтобы поместить базу данных в режим ARCHIVELOG , выполните следующие шаги:

Используя Enterprise Manager

Установите флажок “ARCHIVELOG Mode”.

Щелкните Apply. База данных может быть переведена в режим ARCHIVELOG только из состояния MOUNT .

Щелкните Yes, когда возникнет вопрос, хотите ли Вы перезапустить базу данных.

Используя команды SQL

Смонтируйте базу данных.

Введите команду ALTER DATABASE ARCHIVELOG .

Откройте базу данных.

Перевод базы данных в режим ARCHIVELOG препятствует перезаписи журналов транзакций, пока они не будут заархивированы.

Чтобы перевести базу в этот режим в Enterprise Manager, перейдите к Availability > Recovery Settings и установите флажок режима ARCHIVELOG. База данных должна быть перезапущена после этого изменения.

Чтобы выполнить команду SQL для перевода базы данных в режим ARCHIVELOG, база данных должна быть в режиме MOUNT. Если база данных в настоящий момент открыта, следует чисто завершить ее работу (без опции ABORT), а затем смонтировать ее. Далее показаны команды, позволяющие завершить работу открытой базы данных, поместить ее в режим ARCHIVELOG, и затем открыть ее:

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

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

Отметьте: Сделайте резервную копию своей базы данных после переключения в режим ARCHIVELOG, потому что Ваша база данных восстанавливаема только из первой резервной копии, взятой в этом режиме.

В первой части поста я остановился на онлайн журнальных файлах. Продолжим.

Онлайн журнальные файлы используются по кругу (рис. 1).

Рис. 1. Запись в онлайн журнальные файлы ORACLE.

ARCHIVELOG MODE,
NOARCHIVELOG MODE,

В первом случае, если база данных находится в режиме ARCHIVELOG, то прежде чем процесс записи в онлайн журналы сможет удалить данные и начать писать в журнал, журнальный файл должен быть сохранен в специальную директорию. По-умолчанию, это директория /oracle/<SID>/oraarch (до версии базы данных ORACLE 9i это была директория /oracle/<SID>/saparch). Сохраненные файлы имеют порядковый номер и называются оффлайн журнальными файлами ORACLE. Вид имеют примерно такой:

Это и есть некая история операций с данными во временном срезе с помощью которой можно проводить восстановление базы данных практически на любую точку в прошлом. Стоит отметить, что для восстановления обязательно нужна копия дата файлов базы, на которые можно "накатывать" последовательно журналы. Последовательность крайне важна. Если потеряете хотя бы один оффлайн журнальный файл, дальнейшее восстановление во времени будет невозможно. Копированием онлайн журнальных файлов в оффлайн журнальные файлы занимается процесс ARC0 (Часть I: рис. 1). Он обязательно должен быть запущен, установкой параметра log_archive_start = true.

Так же стоит отметить, что копирование производится в директорию, которая имеет ограниченный размер. Поэтому, если директория переполнится, то работа базы данных будет невозможна. Все операции изменения данных просто "повиснут", так как процесс записи в онлайн журнальные файлы не сможет записать команды изменения данных (SQL запросы типа DELETE, UPDATE, INSERT и так далее). Подробно о важности контроля свободного места в директории /oracle/<SID>/oraarch я писал в этом посте.

Как уже отмечалось, данные файлы очень важны для восстановления системы, поэтому их надо резервировать. SAP рекомендует создавать две копии оффлайн журнальных файлов, после чего удалять их из директории /oracle/<SID>/oraarch.

не нужно выделять отдельную файловую систему и мониторить свободное место в директории /oracle/<SID>/oraarch,
цикл резервного копирования упрощается: делать необходимо только холодные копии базы данных,
немного увеличивается быстродействие работы базы данных и SAP системы соответственно.

Если подытожить, то основной плюс - это снижение трудозатрат администратора системы.

- > alter database NOARCHIVELOG; - перевод базы данных в NOARCHIVELOG режим,
- > alter database ARCHIVELOG; - перевод базы данных в ARCHIVELOG режим.

Команды необходимо выполнять в состоянии базы данных MOUNT.

Для изменения режима необходимо пройти путь по меню:
- (1) Instance management -> (3) Alter database instance -> (3) Set archivelog mode или (4) Set noarchivelog mode

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

Предполагается, что вы инсталлировали базу данных, согласно документа.

Обязательные файлы:

Необязательные файлы:

(необязательные в том смысле, что база может быть настроена для работы без данных файлов) (Alertlog - если нет необходимости в изучении данных по ошибкам, можно удалить. Трассировочные файлы по умолчанию не создаются. Чтобы создавались, нужно включать трассировку и потом не забыть отключить) (По умолчанию не используются. Нужно специально создавать специальными командами.)

Файлы данных (Data Files)

Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления - все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.

В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.

У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.

Данные в файлы вносятся исключительно средствами Oracle.

Следующий запрос, покажет, где находятся файлы данных.

Оперативные файлы журналов повтора (Online Redo Log Files)

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

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

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

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

Управляющие файлы (Control Files)

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

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

Файлы параметров pfile, spfie (Parameter Files)

Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.

spfile - бинарный файл, который используется сервером Oracle при старте.
pfile - текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.

При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.

Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.

Как я могу узнать, что моя база данных использует PFILE или SPFILE?

Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:

Архивные файлы журналов повтора (Archive Log Files)

Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.

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

Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно. Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных. А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.

Alert log и трассировочные файлы (trace file)

При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных - наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.

Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.

Файлы паролей (Password File)

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

Tags: Oracle Database, Файлы базы данных Oracle,

Oracle DBA

Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.

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

Читайте также: