Что-то пошло не так с нашей резервной копией. Что я сделал
выключение db
восстановить резервную копию
перезапустить БД
после этого я получил эту ошибку
ORA-01122: Datenbank-Datei 2 bringt Fehler bei Verifizierungspruefung
ORA-01110: Datendatei 2: 'D:\ORACLE\ORA92ABO\ABO\UNDOTBS01.DBF'
ORA-01207: Datei neuer als Kontrolldatei - alte Kontrolldatei
контрольный файл находится в C: \ oracle ... а файлы базы данных находятся в d: \ oracle \ ora92abo ...
Я предполагаю, что резервная программа между резервным копированием файлов d: \ oracle и c: \ controlfile перезапускает базу данных. поэтому между резервными копиями есть момент, когда база данных работает.
Думаю, это плохо.
Я погуглил, что UNDOTBS01.DBF имеет какое-то отношение к клонированию, и в данный момент мы не используем / не нуждаемся в нем.
РЕДАКТИРОВАТЬ: Подробная информация о методе резервного копирования
шаг 1: выключение через
spool d:\oracle\01shutdon.log
connect / AS SYSDBA
shutdown immediate
exit
шаг 2: передача данных
резервное копирование папки базы данных с синхронизацией с NAS резервное копирование управляющего файла с помощью xcopy на NAS
шаг 3: перезапустить
spool d:\oracle\02startup.log
connect / AS SYSDBA
startup
exit
ОК, вот что делать. Очевидно, подставьте здесь свои собственные значения.
Вам действительно нужно достать и почитать RMAN документация...
Во-первых - при восстановлении вы также восстанавливали контрольный файл? Я знаю, это очевидно, но все равно проверьте.
В Oracle есть функция, называемая SCN, системный контрольный номер. Каждый раз, когда вы выполняете COMMIT, SCN продвигается на 1. SCN для базы данных хранится в заголовке каждой DBF и в управляющем файле. Эта ошибка означает, что файлы данных вашего табличного пространства UNDO (клонирование ??? нет, это связано с откатом - отменой - транзакцией) имеют более высокий SCN, чем контрольный файл. То есть контрольный файл старше, чем DBF.
Как именно вы делали резервные копии? Это с RMAN? Или вы копировали DBF при запущенной базе данных ...? Хорошая новость заключается в том, что если у вас есть хорошая резервная копия, в ней не будет никаких транзакций, о которых вам нужно беспокоиться.
Вы можете решить эту проблему одним из двух способов. Во-первых, вы можете просто продолжать попытки запустить его - каждая попытка запуска увеличивает SCN на 1, так что в конечном итоге контрольный файл будет передавать DBF. Это может занять некоторое время. Или вы можете попробовать воссоздать контрольный файл. Найдите другой Oracle, который работает, и сделайте ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'c:\temp\mycontrolfile.ctl'
; Отредактируйте этот файл, указав имя БД и новые местоположения ваших DBF, запустите и запустите этот сценарий, и он сгенерирует новый файл управления. Тогда вы сможете OPEN RESETLOGS
.
ОДНАКО, если ваша резервная копия плохая, вы ничего не можете сделать.