Назад | Перейти на главную страницу

Oracle 9.2 ORA-01122 проблема с UNDOTBS01.DBF

Что-то пошло не так с нашей резервной копией. Что я сделал

выключение 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

ОК, вот что делать. Очевидно, подставьте здесь свои собственные значения.

  1. удалите UNDOTBS DBF с вашего диска. У вас все еще есть резервная копия, так что все в порядке.
  2. sqlplus / как sysdba
  3. запускать
  4. Он будет жаловаться на отсутствие DBF, не волнуйтесь
  5. изменить системный набор undo_management = manual scope = spfile;
  6. выключение и запуск снова
  7. изменить файл данных базы данных 'D: \ ORACLE \ ORA92ABO \ ABO \ UNDOTBS01.DBF' в автономном режиме;
  8. изменить базу данных открытой;
  9. удалить отмены табличного пространства;
  10. Восстановите табличное пространство UNDO. Вы ДЕЛАТЬ нужно это.
  11. выключение и запуск снова

Вам действительно нужно достать и почитать 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.

ОДНАКО, если ваша резервная копия плохая, вы ничего не можете сделать.