Архивные журнальные файлы (Archived Redo Logs) являються фундаментальным компонентом архитектуры базы данных Oracle‚ обеспечивающим возможность восстановления базы данных до любой точки во времени (Point-in-Time Recovery) и функционирование технологии Data Guard. Перевод базы данных в режим ARCHIVELOG — это обязательное требование для любого производственного окружения (Production)‚ где потеря данных недопустима.

В данной статье мы подробно рассмотрим механизм архивирования‚ параметры инициализации‚ управление через RMAN и SQL*Plus‚ а также типичные проблемы и лучшие практики администрирования.

Теоретические основы: Redo Logs vs Archive Logs

Цикл жизни Redo Log файлов

Оracle использует циклическую запись в Online Redo Log Groups (группы онлайн-журналов повторения). Процесс LGWR (Log Writer) последовательно заполняет группы. Когда текущая группа заполняется‚ происходит переключение журнала (Log Switch)‚ и LGWR начинает писать в следующую группу.

Режимы работы базы данных

• NOARCHIVELOG (по умолчанию): Перезапись онлайн-журналов происходит немедленно после переключения. Восстановление возможно только до момента последнего бэкапа (Cold Backup). Неподходит для 24/7 систем.
• ARCHIVELOG: Перед перезаписью онлайн-журнала‚ фоновый процесс ARCn (Archiver) копирует его содержимое в Archive Log файлы (архивные журналы). Это сохраняет историю всех изменений.

Важно: В версии Oracle 9i и более ранних автоматическую архивацию требовалось включать отдельно параметром LOG_ARCHIVE_START=TRUE. Начиная с Oracle 10g‚ при включении режима ARCHIVELOG автоматическая архивация стартует сразу.

Настройка назначений архивирования (Log Archive Destinations)

Куда именно записываются архивные логи определяется параметрами инициализации. Начиная с Oracle 10g‚ рекомендуется использовать Fast Recovery Area (FRA).

Fast Recovery Area (FRA) — Современный стандарт

FRA — это единое место на диске (или ASM)‚ управляемое Oracle автоматически. Оно хранит: архивные логи‚ бэкапы RMAN‚ флешбэк-логи‚ контрольные файлы.

-- Основные параметры FRA
DB_RECOVERY_FILE_DEST = '/u01/app/oracle/fast_recovery_area' -- Путь к FRA
DB_RECOVERY_FILE_DEST_SIZE = 50G -- Жесткий лимит размера FRA

Если FRA настроена и параметр LOG_ARCHIVE_DEST_1 не задан явно (или задан как LOCATION=USE_DB_RECOVERY_FILE_DEST)‚ архивные логи автоматически складываются в подкаталог ARCHIVELOG внутри FRA с иерархией по датам:

/u01/app/oracle/fast_recovery_area/ORCL/ARCHIVELOG/2026_07_11/o1_mf_1_1234_abcdefgh_.arc

Явное указание путей (LOG_ARCHIVE_DEST_n)

Можно задать до 31 назначения (LOG_ARCHIVE_DEST_1 … LOG_ARCHIVE_DEST_31). Параметр LOG_ARCHIVE_DEST (без номера) устарел‚ но поддерживается для совместимости.

-- Пример явной настройки двух назначений: локальное и удаленное (Data Guard)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=/opt/oracle/archive VALID_FOR=(ALL_LOGFILES‚ALL_ROLES) DB_UNIQUE_NAME=PRIM';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=STANDBY_DB ASYNC VALID_FOR=(ONLINE_LOGFILES‚PRIMARY_ROLE) DB_UNIQUE_NAME=STBY';

Ключевые атрибуты назначения:

• LOCATION — локальный путь к файловой системе или ASM дискгруппе.
• SERVICE — сетевой сервис для передачи логов на Standby (Data Guard).
• VALID_FOR — когда это назначение активно (роль БД‚ тип логов).
• MANDATORY / OPTIONAL — обязательно ли успешное архивирование для переключения лога. Если MANDATORY и место кончилось — БД «зависнет» (HANG) на событии log file switch (archiving needed).

Формат имени файла (LOG_ARCHIVE_FORMAT)

Определяет шаблон имени архивного файла. Обязательные переменные: %t (thread)‚ %s (sequence)‚ %r (resetlogs_id). Рекомендуется добавлять %d (DB_NAME).

ALTER SYSTEM SET LOG_ARCHIVE_FORMAT = '%t_%s_%r_%d.arc' SCOPE=SPFILE;
-- Пример результата: 1_1234_1122334455_ORCL.arc

Включение и отключение режима ARCHIVELOG

Требует перезапуска базы данных в режиме MOUNT.

1. Проверка текущего режима:

   SQL> ARCHIVE LOG LIST;
   Database log mode Archive Mode
   Automatic archival Enabled
   Archive destination USE_DB_RECOVERY_FILE_DEST
   Oldest online log sequence 1234
   Next log sequence to archive 1236
   Current log sequence 1236

2. Включение (Enable):

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   ALTER DATABASE ARCHIVELOG;
   ALTER DATABASE OPEN;
   -- Рекомендуется сразу сделать полный бэкап (Level 0)

3. Отключение (Disable):

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   ALTER DATABASE NOARCHIVELOG;
   ALTER DATABASE OPEN;

Управление архивными логами вручную (SQL*Plus)

Принудительное переключение журнала

Часто используется для создания архивного лога «здесь и сейчас» (например‚ перед бэкапом контрольного файла или для синхронизации Standby).

ALTER SYSTEM SWITCH LOGFILE;
-- Или для конкретной нити (RAC):
ALTER SYSTEM SWITCH LOGFILE THREAD 2;

Принудительная архивация

Команда заставляет процессы ARCn архивировать все заполненные‚ но еще не заархивированные онлайн-журналы.

ALTER SYSTEM ARCHIVE LOG ALL;
-- Архивировать конкретную последовательность:
ALTER SYSTEM ARCHIVE LOG SEQUENCE 1234 THREAD 1;

Остановка/Запуск процесса архивирования

-- Остановить автоматическую архивацию (требует ручного ALTER SYSTEM ARCHIVE LOG ALL)
ALTER SYSTEM ARCHIVE LOG STOP;

-- Запустить автоматическую архивацию
ALTER SYSTEM ARCHIVE LOG START;

Работа с архивными логами через RMAN (Recovery Manager)

RMAN, основной инструмент для бэкапа‚ проверки и удаления архивных логов. Он ведет каталог (в controlfile или Recovery Catalog) и знает‚ какие логи нужны для восстановления.

Просмотр списка архивных логов

RMAN> LIST ARCHIVELOG ALL;

-- С фильтрами
RMAN> LIST ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 200;
RMAN> LIST ARCHIVELOG FROM TIME 'SYSDATE-7' UNTIL TIME 'SYSDATE-1';

Пример вывода (из предоставленных данных):

List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- — ------------------- ----
10 1 12 A 25-MAR-11 /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_03_30/o1_mf_1_12_6s4mhvrb_;arc
11 1 13 A 30-MAR-11 /u01/app/oracle/fast_recovery_area/ORCL/archivelog/2011_03_30/o1_mf_1_13_6s4mjcwg_.arc
...
Status: A — Available‚ X — Expired‚ D ⸺ Deleted‚ U — Unavailable

Бэкап архивных логов

-- Только архивные логи
BACKUP ARCHIVELOG ALL;

-- Архивные логи + текущий онлайн-лог (рекомендуется для консистентности)
BACKUP ARCHIVELOG ALL PLUS ARCHIVELOG;

-- С удалением после успешного бэкапа (очистка диска)
BACKUP ARCHIVELOG ALL DELETE INPUT;
-- DELETE INPUT удаляет только те копии‚ которые были забэкаплены.
-- DELETE ALL INPUT удаляет все копии со всех назначений (если дуплексирование).

Удаление архивных логов (О логов

Критически важно: Удалять файлы вручную через ОС (rm) НЕЛЬЗЯ. Это ломает репозиторий RMAN. Удаление только через RMAN.

-- Удалить логи‚ заархивированные более 7 дней назад‚ которые уже забэкаплены 1 раз на ленту/диск
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' BACKED UP 1 TIMES TO DEVICE TYPE DISK;

-- Удалить устаревшие (по политике RETENTION POLICY)
DELETE OBSOLETE;

-- Физическое удаление файлов‚ помеченных EXPIRED (не найдены на диске при CROSSCHECK)
DELETE EXPIRED ARCHIVELOG ALL;

Синхронизация репозитория с реальностью (CROSSCHECK)

Если файлы были удалены вручную или перенесены‚ RMAN не знает об этом до команды CROSSCHECK.

CROSSCHECK ARCHIVELOG ALL;
-- Пометит отсутствующие файлы как EXPIRED.
-- После этого нужно выполнить DELETE EXPIRED ARCHIVELOG ALL для чистки каталога.

Мониторинг и диагностика проблем

Ключевые динамические представления (V$ Views)

Типовые проблемы и решения

Проблема 1: FRA заполнена на 100% (ORA-19809‚ ORA-19804)

Симптомы: База данных зависает‚ в Alert Log: «ORA-19815: WARNING: db_recovery_file_dest_size of X bytes is 100.00% used».

Решение:

1. Срочно сделать бэкап архивных логов на внешнее хранилище: BACKUP RECOVERY AREA; или BACKUP ARCHIVELOG ALL DELETE INPUT;.
2. Увеличить DB_RECOVERY_FILE_DEST_SIZE (если есть место на диске): ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=100G SCOPE=BOTH;.
3. Удалить устаревшие бэкапы: DELETE OBSOLETE;.
4. Как последнее средство — удалить логи‚ которые гарантированно забэкаплены: DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE SBT_TAPE;.

Проблема 2: «Log file switch (archiving needed)» — зависание БД

Причина: Онлайн-журналы переключаются быстрее‚ чем успевает отработать ARCn‚ или назначение MANDATORY недоступно/заполнено.

Диагностика:

SELECT dest_id‚ status‚ error‚ destination FROM v$archive_dest WHERE status != 'INACTIVE';

Лечение: Устранить ошибку в DEST (свободное место‚ сеть для Standby)‚ либо временно сделать назначение OPTIONAL / DEFER:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY;

Проблема 3: Архивные логи «валяются» в рутовой партиции (как в примере из интернета: /export/home/arch)

Риск: Заполнение корневой файловой системы (/) приводит к крашу ОС и БД.

Решение: Перенастроить LOG_ARCHIVE_DEST_1 на выделенную файловую систему или FRA на отдельном диске/ASM;

Лучшие практики (Best Practices)

1. Всегда используйте FRA. Это упрощает управление пространством и политиками хранения.
2. Настройте RETENTION POLICY в RMAN. Например: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;. Тогда DELETE OBSOLETE будет работать предсказуемо.
3. Дуплицируйте архивные логи (Multiplexing). Минимум 2 локальных назначения (например‚ FRA + отдельный диск/ASM) или FRA + Standby.

   LOG_ARCHIVE_DEST_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST MANDATORY'
   LOG_ARCHIVE_DEST_2 = 'LOCATION=/mnt/archivelog_backup OPTIONAL'

4. Мониторьте задержку архивирования (Archive Lag). Используйте V$ARCHIVE_DEST_STATUS.GAP_STATUS и метрики Enterprise Manager / Cloud Control.
5. Включите Block Change Tracking для ускорения инкрементных бэкапов‚ что косвенно снижает нагрузку на архивирование при частых бэкапах.
6. Регулярно проверяйте восстанавливаемость. RESTORE VALIDATE ARCHIVELOG ALL;.
7. Не храните архивные логи вечно. Определите RPO/RTO и настройте политику удаления соответственно.

Специфические сценарии

Oracle RAC (Real Application Clusters)

• У каждой нити (Instance/Thread) своя последовательность номеров логов.
• Архивные логи всех нитей должны быть доступны на всех нодах для восстановления (обычно через Shared Storage / ACFS / NFS).
• Параметр LOG_ARCHIVE_DEST_1 должен указывать на кластерную файловую систему или ASM.
• Команда ALTER SYSTEM SWITCH LOGFILE переключает лог только на текущей ноде. Для глобального переключения используйте ALTER SYSTEM ARCHIVE LOG CURRENT (до 11g) или скрипты на всех нодах.

Data Guard (Physical Standby)

• На Primary: LOG_ARCHIVE_DEST_2 = 'SERVICE=standby_tns ASYNC VALID_FOR=(ONLINE_LOGFILES‚PRIMARY_ROLE) DB_UNIQUE_NAME=standby'.
• На Standby: Архивные логи применяются процессом MRP (Managed Recovery Process).
• Важно мониторить V$ARCHIVE_GAP и V$DATAGUARD_STATS (apply lag‚ transport lag).

Перемещение архивных логов (Relocation)

Если нужно физически переместить файлы (например‚ на новый диск)‚ правильная процедура:

1. BACKUP ARCHIVELOG ALL FORMAT 'new_location/%U' DELETE INPUT; (RMAN скопирует и обновит репозиторий).
2. Или: ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=new_path' SCOPE=BOTH; + перезапуск архивирования. Старые логи останутся на старом месте (их нужно чистить вручную или оставить для восстановления).

Чек-лист для DBA: Ежедневный/Еженедельный осмотр

• [ ] Пространство FRA: SELECT * FROM V$RECOVERY_FILE_DEST; (Usage < 85%).
• [ ] Статус DEST: SELECT dest_id‚ status‚ error FROM v$archive_dest WHERE target='PRIMARY'; (Все VALID).
• [ ] Data Guard Lag: SELECT * FROM v$dataguard_stats WHERE name LIKE '%lag%'; (в пределах SLA).
• [ ] Успешность бэкапа логов: Проверить RMAN лог или V$RMAN_BACKUP_JOB_DETAILS.
• [ ] CROSSCHECK: Еженедельно CROSSCHECK ARCHIVELOG ALL; DELETE EXPIRED ARCHIVELOG ALL;.
• [ ] Alert Log: Нет ли ошибок ORA-19504‚ ORA-27072‚ ARCH: Error.

Грамотное управление архивными журналами (Archive Logs) — это фундамент отказоустойчивости базы данных Oracle. Ключевые пиляры успеха:

1. Работа в режиме ARCHIVELOG.
2. Использование Fast Recovery Area (FRA) с жестким лимитом размера (DB_RECOVERY_FILE_DEST_SIZE).
3. Исключительное использование RMAN для любых операций с архивными логами (бэкап‚ удаление‚ верификация).
4. Настроенный мониторинг заполнения дисков и статуса процессов архивирования (V$ARCHIVE_DEST).
5. Понятная политика удержания (Retention Policy)‚ согласованная с бизнесом (RPO/RTO).

Соблюдение этих правил спасет вас от ночных звонков «ORA-00257: archiver error. Connect internal only‚ until freed» и гарантирует возможность восстановления бизнеса в любой момент времени.

Статья подготовлена на основе документации Oracle Database 19c/21c/23c и лучших практик администрирования. Актуально на ;