07июл
ARCHIVELOG или NOARCHIVELOG? Вот в чем вопрос?
Самая ПЕРВАЯ обязанность администратора – поддержка базы данных в рабочем состоянии. Даже если в системе происходит сбой (пропало питание, носитель пришел в непригодность и т.д.), администратор должен в максимально сжатые сроки поднять базу без потерь данных. Значит, к сбоям администратор должен готовиться загодя.
Для начала администратор должен решить вопрос: ARCHIVELOG или NOARCHIVELOG? Исходя из ответа на него, и будет строиться стратегия резервирования.
Выполните следующий запрос, чтобы знать режим работы ваше базы:
select log_mode from v$database;
При эксплуатации базы данных в режиме NOARCHIVELOG формируются данные для восстановления лишь при сбое экземпляра (instance recovery) – оперативные журналы повторного выполнения. Такая ситуация возникает, например , при отключении питания.
При эксплуатации базы данных в режиме ARCHIVELOG формируются данные для восстановления как при сбое экземпляра (instance recovery), так и при сбое носителя (media recovery) – оперативные и архивные журналы повторного выполнения.
Каждый способ имеет преимущества и недостатки (см. таблицу). Поэтому администратору приходится самому решать проблему выбора.
| ARCHIVELOG | NOARCHIVELOG |
| Дополнительная нагрузка на сервер | + | - |
| Восстановление без потерь данных | + | - |
| Горячее резервное копирование | + | - |
| Возможность создания «горячей» резервной базы данных (standby) | + | - |
| Восстановление на указанный момент времени | + | - |
| Instance recovery | + | + |
| Media recovery | + | - |
| Необходимость наличия носителей больших объемов | + | - |
Главное:
В режиме noarchivelog восстановление возможно только на момент создания последнего бэкапа.
В режиме archivelog восстановление возможно до момента времени последней фиксации транзакции.
Мое решение: тестовая база – NOARCHIVELOG; промышленная – ARCHIVELOG. И будь почти спокоен!