Извлечение данных из умершей БД

У заказчика.
Версия: Oracle DB 11g2 (11.2.0.1) 32 бита.
Размер БД - порядка 1 TB.
БД была в NOARCHIVE MODE. (3 redo-log-файла, из них было 2 ACTIVE и 1 CURRENT - обычное дело для "старых" установок" продукта)
Был сделан shutdown abort местным админом. (не уверен, но кажется была проблема с местом где лежали system, sysaux, undo, redo)
2 папки - в одной лежали system, sysaux, undo, redo, controlfile; в другой - данные ( и кажется это были разные физические устройства I/O, разные точки монтирования).
Тейблспейсы c данными - "EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M"
Было сделано копирование папки со всеми файлами на ленту.

При попытке проверить файл system01.dbf c помощью dbv, возвращается ошибка "unknown format". Т.е dbv не распознает формат файла, тогда как другие файлы были проверены без ошибок.

Можно сделать точно такую же бД, но пустую, т.е схемы все известны, определения объектов, так же известны.

Есть какой-нибудь способ извлечь данные из сохранившихся файлов БД?
В какую сторону копать?

maxski,

Бекап базы есть или как всегда?

Нет, бэкапа нет.
Есть только холодный бэкап файлов, из которых system01.dbf - не читается ораклом.

maxski,

А проблема-то в чем? База не стартует? Ошибки есть? Какие?

Да, база отказалась стартовать, не помню точно, но что-то было с файлом system01.dbf
Я его проверил, dbv - завершился с ошибкой. Сам файл содержит какие-то данные, незабит нулями.

[oracle@kgliwfw orcl]$ dbv file='/db/orcl/orcl/system01.dbf' DBVERIFY: Release 11.2.0.1.0 - Production on Thu Mar 17 14:34:45 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. DBV-00107: Unknown header format (11) (201326603)

Другой файл - нормальный

[oracle@kgliwfw ~]$ dbv file='/db/orcl/orcl/system02.dbf' DBVERIFY: Release 11.2.0.1.0 - Production on Thu Mar 17 15: Copyright (c) 1982, 2009, Oracle and/or its affiliates. Al DBVERIFY - Verification starting : FILE = /db/orcl/orcl/sys DBVERIFY - Verification complete Total Pages Examined : 3538944 Total Pages Processed (Data) : 3525125 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 13662 Total Pages Failing (Index): 0 Total Pages Processed (Other): 35 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 122 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 3209936849 (0.3209936849)

Изначально планировалось перенести БД с 32-х на 64 разряда, с 11g1 на 11g2.
Тот человек, который начал это дело. Не смог этого сделать, что он конкретно делал, сейчас не ясно.
Мне этот холодный бэкап достался без контрол-файла. Я сгенерил скрипт для создания контрол-файла и по содержимому папок вписал в скрипт все имена файлов.
После в nomount cделал контрол-файл и попытался стартовать бд. И получил ошибку, что-то типа system01.dbf unknown format.
На этом все остановилось. Файлы сейчас хранятся на "ленте", "лента" примонтирована на другую машину. Сейчас я имею доступ на эту машину.
Успел поиследовать различные тулзы:
http://www.oracle-internals.com/?p=17
Пока ничего конкретного.
Есть какие-нибудь идеи?

автор
(3 redo-log-файла, из них было 2 ACTIVE и 1 CURRENT - обычное дело для "старых" установок" продукта)

Долго думал на этой фразой, но так ничего и не понял, что этим хотел сказать автор.

Вообщем, это было узким местом - недостаточное количество online redolog group.
Поэтому я часто наблюдал такую картину:

SQL> select GROUP#, MEMBERS, STATUS from v$log; GROUP# MEMBERS STATUS ---------- ---------- ---------- 1 1 CURRENT 2 1 ACTIVE 3 1 ACTIVE 3 rows selected. SQL>

И в алерт-логе было что-то типа:

"Thread 1 cannot allocate new log, sequence 77805 Checkpoint not complete"

maxski
Вообщем, это было узким местом - недостаточное количество online redolog group. Поэтому я часто наблюдал такую картину: SQL> select GROUP#, MEMBERS, STATUS from v$log; GROUP# MEMBERS STATUS ---------- ---------- ---------- 1 1 CURRENT 2 1 ACTIVE 3 1 ACTIVE 3 rows selected. SQL> И в алерт-логе было что-то типа: "Thread 1 cannot allocate new log, sequence 77805 Checkpoint not complete"

И поэтому ждя базы был сделан shutdown abort?

Кто же холодный бэкап делает для базы после shutdown abort.

Нужно попытаться восроизвести ситуацию, соответствующую после команды shutdown abort.
То есть расположить все файлы данных, где они были.
Создать правильно контрольный файл, указать в нём NORESETLOGS.
Всё реду-логи должны быть доступны.
Возможно после
1)startup mountl
2) recover;
База и откроется.

Если реду логов нет, то скорее всего тот сбой system02.dbf никак уже не исправить.

очень холодный бэкап
Возможно после 1)startup mountl 2) recover; База и откроется. Если реду логов нет, то скорее всего тот сбой system02.dbf никак уже не исправить.

Не точно сказал.
Имел ввиду, что после Recovery instance, база поднимется.
Поэтому просто startup;

очень холодный бэкап,

если хедр у систем не читается то уже поздно пить recover)