02ноя
Поврежден журнал повторного выполнения, который нужен для восстановления (inactive,active). Что делать и как быть? Параметр _allow_resetlogs_corruption.
Если поврежден неактивный файл, то это вообще не проблема: удаляется и создается заново.
Если поврежден активный или текущий файл?
Если база данных открыта и поврежден оперативный (активный, текущий или неактивный, который нельзя удалить) журнальный файл, то работа с ней приостановливается - архивирование не может быть выполнено. В этой ситуации нельзя останавливать базу. Пробуйте сделать следующие шаги:
ALTER SYSTEM CHECKPOINT для активного журнала
ALTER SYSTEM SWITCH LOGFILE для текущего журнала
А затем почистить файл:
ALTER DATABASE CLEAR LOGFILE GROUP NN
или , если файл незаархивирован :
ALTER DATABASE CLEAR UNARCHIVED LOGFILE NN
Если же "вылетел" хотя бы один файл данных, то он невосстанавливаем. Этим файлом данных можно пожертвовать, используя конструкцию UNRECOVERABLE DATAFILE.
И если все получилось и база данных доступна для дальнейшей работы, то обязательно как можно быстрее сделайте холодный бекап. Это связано с тем, что очищенный журнальный файл не годен для восстановления.
Если же база закрыта или вышеизложенное не помогло, то первое, что необходимо сделать – сохранить, то что есть: датафайлы, редо логи, undo, вообще всю базу. Так как неясно во что превратятся ваши мытарства, а вернуться к исходной точке захочется. После чего пробуем неполное восстановление (до утерянного журнала) :
recover database until cancel
alter database open resetlogs
и опять сделать холодный бекап (реинкарнация произошла)
Если и это у вас не получилось, и вы уверены, что ВСЕ варианты исчерпаны, то пробуйте использовать незадокументированный параметр "_allow_resetlogs_corruption".
Еще раз повторю: если вы все возможности восстановления исчерпали, только тогда можно открывать базу таким путем. Потому, что установка этого параметра вынуждает базу открываться в несогласованном состоянии.
То есть ваша БД будет пребывать в непредсказуемое состоянии:может быть поврежден словарь, нарушены правила целостности и прочие неприятности.
Сразу после открытия базы, нужно экспортировать все схемы, создавать новую базу данных и импортировать в нее всю информацию.
Как использовать _allow_resetlogs_corruption?
Сначала все-таки еще раз попробуйте без него:
- Остановить базу и сделать полный бэкап.
- STARTUP MOUNT
- Проверьте, что все файлы данных пребывают в статусе END BACKUP:
SELECT 'alter database datafile '||file_name||' END BACKUP;' from v$datafile;
- ALTER DATABASE OPEN RESETLOGS;
- Если база данных требует восстановления, то выполните восстановление типа UNTIL CANCEL и примените все доступные архивные и оперативные журнальные файлы. После чего введите CANCEL и повторно выполните команду ALTER DATATBASE OPEN RESETLOGS.
- Если же база требует такие журналы, которых у вас нет, или все предыдущие усилия не увенчались успехом, то выполните остановку базы.
- Включитесь в файл инициализации следующую строку:
_allow_resetlogs_corruption=TRUE
- STARTUP MOUNT
- Снова проверьте статус датафайлов : SELECT 'alter database datafile '||file_name||' END BACKUP;' from v$datafile;
- ALTER DATABASE OPEN RESETLOGS;
- Если база данных требует восстановления, то выполните восстановление типа UNTIL CANCEL и примените все доступные архивные и оперативные журнальные файлы. После чего введите CANCEL и повторно выполните команду ALTER DATATBASE OPEN RESETLOGS.
- Если все таки база открылась, то немедленно делайте полный экспорт базы данных, или экспорт схем, которые Вам нужно восстанавливать.
- Останавливайте базу
- Перестраивайте базу
- Выполняйте импорт
- Выполните холодный бэкап.
Неплохо выполнить ANALYZE TABLE…VALIDATE STRUCTURE CASCADE таблиц, после того как база открылась, перед выполнением экспорта.
Надеюсь, что этот пост вам помог. Успехов!