Восстановление базы данных — задача, с которой хотелось бы не сталкиваться, но при аварии она может спасти бизнес. В финансовых системах и ERP даже небольшая ошибка способна привести к серьезным последствиям. Поэтому восстановление по System Change Number (SCN) важно для защиты от повреждения данных и ошибок пользователей.
Иногда базу Oracle нужно вернуть не просто к определенной дате, а к состоянию до конкретного изменения. В статье рассмотрены назначение SCN, подготовка и восстановление с помощью RMAN или SQL*Plus, а также защита данных средствами Vinchin.
Что такое SCN при восстановлении базы данных?
System Change Number, или SCN, — внутренний логический номер, который Oracle Database использует для упорядочивания событий и обеспечения согласованности данных. SCN отражает положение изменения в истории базы; при фиксации транзакции Oracle записывает SCN ее завершения.
В отличие от обычной временной метки SCN задает логическую точку в истории базы и не зависит от отображаемого часового пояса. Для RMAN условие UNTIL SCN N означает восстановление до SCN N, не включая его. Поэтому важно различать последнее сохраняемое изменение и номер, заданный как верхняя граница восстановления.
Зачем восстанавливать базу данных до заданного SCN?
Представьте, что важные данные зарплатного учета случайно удалены в 14:03, а в ту же минуту выполнено несколько других изменений. Одна временная метка может оказаться недостаточно точным ориентиром. Если известен SCN ошибочного изменения, можно точнее задать границу восстановления.
Такой подход полезен после случайного удаления данных или сбоя пакетного задания. Однако неполное восстановление всей базы возвращает назад всю базу, а не только ошибочную транзакцию: нормальные изменения после выбранной точки также не сохранятся. Заранее согласуйте допустимую потерю данных и остановку сервиса.
В средах с требованиями к аудиту SCN помогает однозначнее документировать выбранную границу восстановления. Его использование само по себе не гарантирует соблюдения всех нормативных требований.
Что проверить перед восстановлением?
Подготовка помогает избежать ошибок и длительного поиска недостающих файлов во время восстановления.
Проверьте резервные копии средствами RMAN. Например, следующая команда проверяет выбранные RMAN файлы резервных копий без записи восстановленных файлов:
RESTORE DATABASE VALIDATE;
Убедитесь, что доступны подходящая резервная копия и все необходимые redo-данные от ее состояния до выбранной границы. Примеры предполагают режим ARCHIVELOG и доступный подходящий управляющий файл. Восстановление утраченного control file или SPFILE требует дополнительных действий, которые здесь не рассматриваются.
Проверьте свободное место на исходном и целевом серверах. Зафиксируйте текущую инкарнацию базы данных и историю OPEN RESETLOGS: это важно при выборе копий, управляющего файла и архивных журналов.
Примеры ниже относятся к восстановлению всей базы, а не отдельной таблицы или PDB. Перед применением проверьте особенности своей версии Oracle, CDB/RAC и конфигурации хранения. Команды SHUTDOWN, RESTORE и OPEN RESETLOGS изменяют состояние базы; сначала отработайте процедуру на изолированном стенде.
Как восстановить базу данных до SCN с помощью RMAN?
RMAN (Recovery Manager) — штатное средство Oracle для резервного копирования и восстановления. Оно автоматизирует выбор копий и многие операции применения redo.
Для просмотра текущего SCN выполните в SQL*Plus с необходимыми правами:
SELECT CURRENT_SCN FROM V$DATABASE;
Для просмотра диапазонов SCN в архивных журналах:
SELECT SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE#;
CURRENT_SCN показывает текущее состояние, а не автоматически найденную точку до ошибки. Диапазоны журналов также не определяют ошибочную транзакцию сами по себе: целевую границу нужно установить по известной истории изменений или другим диагностическим данным. Для RAC и нескольких инкарнаций дополнительно учитывайте поток redo и RESETLOGS.
После определения границы выполните следующие действия:
1. Завершите работу базы в SQL*Plus.
SHUTDOWN IMMEDIATE;
SHUTDOWN ABORT используйте только при необходимости и с пониманием последствий, если штатное завершение недоступно.
2. Запустите базу в состоянии MOUNT.
STARTUP MOUNT;
3. Подключите RMAN к нужной целевой базе.
Используйте учетную запись с необходимыми административными правами. Например, при локальной аутентификации ОС команда выполняется в оболочке настроенного сервера Oracle:
rman target /
4. Просмотрите необходимые резервные копии и журналы.
В RMAN замените <your_scn> на проверенное числовое значение верхней границы:
RUN {
SET UNTIL SCN <your_scn>;
RESTORE DATABASE PREVIEW;
}PREVIEW использует метаданные и не читает содержимое файлов резервных копий. Это предварительный просмотр плана, а не замена проверки доступности и целостности файлов.
5. Выполните восстановление в RMAN.
RUN {
SET UNTIL SCN <your_scn>;
RESTORE DATABASE;
RECOVER DATABASE;
}Используйте одну и ту же границу при выборе копий и применении redo. Например, чтобы включить изменения до SCN 1418900, задают UNTIL SCN 1418901. Подставлять примерное число в рабочую базу нельзя.
6. После успешного завершения откройте базу с RESETLOGS.
В SQL*Plus выполните:
ALTER DATABASE OPEN RESETLOGS;
Если целевая точка относится к предыдущей инкарнации, может потребоваться RESET DATABASE TO INCARNATION <incarnation_key> в RMAN. Не выполняйте эту команду только потому, что в истории уже был RESETLOGS: сначала определите нужную ветвь восстановления и проверьте доступность ее копий и журналов.
Для сжатых и многосекционных резервных копий убедитесь, что установленная версия и используемые средства поддерживают их восстановление. Отсутствие необходимых архивных журналов может остановить RECOVER до достижения выбранной границы.
Как восстановить базу данных до SCN с помощью SQL*Plus?
SQL*Plus позволяет DBA управлять восстановлением вручную, но требует внимательного контроля файлов и сообщений Oracle. Целевой SCN определяют заранее, как и в варианте с RMAN.
Порядок ручного восстановления:
1. Завершите работу базы.
SHUTDOWN IMMEDIATE;
2. Запустите базу в состоянии MOUNT.
STARTUP MOUNT;
3. Восстановите физические файлы данных из подходящей резервной копии. Это выполняется вне SQL*Plus средствами ОС, например cp в Linux, если копия представляет собой пригодные для такого восстановления файлы данных. Нельзя просто скопировать RMAN backup piece на место datafile. Проверьте пути; если расположение изменилось, при необходимости обновите ссылки через ALTER DATABASE RENAME FILE.
4. Запустите восстановление носителя в SQL*Plus.
RECOVER DATABASE UNTIL CHANGE <your_scn>;
В команде UNTIL CHANGE также задается исключающая верхняя граница. Замените заполнитель на числовое значение, выбранное для своей базы.
5. Предоставляйте необходимые архивные журналы. По запросам SQL*Plus указывайте полные пути к файлам и следите за сообщениями о применении redo и завершении восстановления.
6. После успешного восстановления откройте базу.
ALTER DATABASE OPEN RESETLOGS;
Если нужного журнала нет, выбранная точка может оказаться недостижимой. Копии, снятые во время работы базы, должны быть созданы корректным способом и иметь необходимые redo-данные. Условие USING BACKUP CONTROLFILE требуется при восстановлении с резервным управляющим файлом, а не просто из-за использования горячей резервной копии.
Перед применением к рабочей базе тщательно проверьте ручную процедуру: обработка ошибок и проверка результата остаются ответственностью администратора.
Рекомендации по восстановлению на основе SCN
Для более предсказуемого восстановления полезны следующие практики:
Регулярно сохраняйте значения CURRENT_SCN вместе с временными метками и данными мониторинга. Такая история помогает сопоставлять события при расследовании инцидента, хотя не заменяет диагностику конкретной транзакции.
Автоматизируйте проверку наличия и состояния архивных журналов. Периодически выполняйте тестовое восстановление на изолированной копии, не затрагивающей рабочие файлы и область восстановления production-базы.
После существенных изменений и OPEN RESETLOGS пересмотрите стратегию и создайте актуальную резервную копию. RESETLOGS начинает новую инкарнацию, но сам по себе не делает все прежние копии непригодными: их использование зависит от истории инкарнаций и доступных журналов.
Ведите инструкции по восстановлению с учетом локальных путей, сетевых хранилищ для удаленных копий и контактов ответственных специалистов.
Защита баз данных с Vinchin Backup & Recovery
Помимо штатных инструментов и ручных процедур для корпоративной защиты данных можно использовать Vinchin Backup & Recovery. Решение поддерживает резервное копирование различных СУБД, включая Oracle, MySQL, SQL Server, MariaDB, PostgreSQL/Postgres Pro и MongoDB; доступность конкретной платформы и функций нужно проверять для выбранной версии продукта.
В поддерживаемых конфигурациях доступны сжатие на стороне источника и инкрементное резервное копирование Oracle, групповые задания, гибкие политики хранения, включая GFS, и защита от программ-вымогателей. Возможности облачного хранения и ленточного архивирования зависят от конфигурации и типа защищаемых данных.
Веб-консоль организует создание задания в четыре этапа. На иллюстрациях исходной статьи показан пример для SQL Server; экран настройки Oracle может отличаться.
1. Выберите базы данных для защиты.
2. Выберите целевое хранилище.
3. Настройте расписание, сроки хранения и политики.
4. Проверьте параметры и создайте задание.
Оцените возможности Vinchin Backup & Recovery с помощью 60-дневной полнофункциональной пробной версии.
Часто задаваемые вопросы о восстановлении до SCN
1. Можно ли автоматически сохранять текущие SCN базы?
Да. Можно запускать запрос CURRENT_SCN к V$DATABASE по расписанию через cron или Планировщик заданий Windows и сохранять результат вместе с датой и идентификатором базы. Учетной записи нужны соответствующие права.
2. Что делать, если архивные журналы находятся в разных каталогах?
Если файлы не известны репозиторию RMAN, зарегистрируйте их через CATALOG START WITH, указывая подходящий префикс пути. Проверьте предложенный список и подтвердите регистрацию нужных файлов. Уже зарегистрированные журналы не требуется повторно добавлять только из-за разных каталогов.
3. Есть ли дополнительные сложности при восстановлении большой базы?
Большой объем увеличивает продолжительность операции и требования к дискам и сети. После восстановления проверьте целостность средствами Oracle и работу приложений. DBVERIFY может использоваться для проверки поддерживаемых файлов данных, но не заменяет проверку бизнес-данных и всей процедуры восстановления.
Заключение
Восстановление Oracle до заданной границы SCN позволяет точнее определить состояние, к которому нужно вернуть базу после ошибки. Для этого доступны автоматизированные операции RMAN и ручное восстановление через SQL*Plus. Успех зависит от правильной границы, подходящих копий, необходимых redo-данных и проверенной процедуры. Средства корпоративного резервного копирования, включая Vinchin, дополняют эту стратегию защиты.
