Oracle v6 Datafile Corrupted - HELP !!!

I have a new client that has called me in for some help, and I'm not how to proceed. The scenario I've inherited:

• Oracle 6.0.34
• VMS 5.5
• 8-GB database
• NOARCHIVELOG mode
• 11 files
• 2 tablespaces (SYSTEM / USER_SPACE)
• data / indexes / temp / rollback randomly mixed throughout both tablespaces.

They had a database crash last week - they're not sure exactly what happened, and they have no DBA. When they tried to restart they get an "ORA-01122: datafile <filename> failed verification check." This is when they called me.

I was able to do a STARTUP MOUNT, followed by an ALTER DATAFILE <filename> OFFLINE (works in v6, not in v7 under noarchivelog). Then I was able to ALTER DATABASE OPEN. I tried at various points RECOVER DATABASE and RECOVER DATAFILE, but they started prompting me for archive files that of course don't exist. Now it says "media recovery not necessary" or something to that effect.

The admin guy at the client restored the file from a backup (a few weeks ago) but the same verification check failure (ORA-01122) occurs. I've called Oracle support, and they were helpful but not real confident that they can get things working under v6 and noarchivelog.

Anyway, I can query the database, but of course not any tables that have extents in the affected datafile. Unfortunately, their last cold backup was a few weeks ago (deadlines caused them to not be able to shutdown for backups - always happens that way, eh?). And, I'm not 100% confident that the backup is any good - the first restore should have worked - the database worked fine at the point that backup was taken, but now it still seems corrupted.

So my plan now is to export anything I can from the database to salvage at least the non-affected tables. Then restore the entire cold backup, and see what happens. If it opens, bingo, and we can at least apply those exports to roll forward some data. If not, we construct a new db. Apparently a good deal of the data can be reloaded from raw files, but must go through lengthy processing, and it's an old slow machine, so we'd like to minimize that.

Any other ideas out there? It's getting kind of urgent! Any help much appreciated.

Chris
AVANCO International, Inc.
toneczar_at_erols.com
http://www.serve.com/cowpb/chamilton.html Received on Tue Jun 30 1998 - 15:48:25 CDT