ORA-01206: File is not part of this database - wrong database id

This was posted yesterday on Oracle-L by Li Li. I feel I should blog about it to spread the word, especially since not everyone in this world performs test-restores. Li was executing a test-restore and hit a problem at the end of the point-in-time recovery phase:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01122: database file 9 failed verification check ORA-01110: data file 9: 'H:\xxx\xxx\xxx.dbf'

The Root Cause: Read-Only Tablespaces and RMAN Duplicate

Datafile 9 was a read-only tablespace, and the source database was actually created with RMAN DUPLICATE. Datafile 9 was read-only during that duplicate operation, and the status hadn't changed since then.

As you can imagine, the read-only datafiles were not changed and their headers still contained the DBID of the database that was the source of the RMAN DUPLICATE. A similar situation could probably happen if tablespaces were imported using transportable tablespaces feature, and left read only.

The Solution: Updating Datafile Headers

The fix in this case is to make tablespaces read-write for a moment, and then change back to read-only. The read-write operation will write new datafile headers and, consequently, put there the "right" DBID.

Prevention and Recovery Options

IMPORTANT -- this has to be done before backup and not after a disaster strikes. This case just emphasizes again the most important rule of any backup/recovery strategy is to do regular test-restores.

If it's too late and something hit the fan -- well, you probably have a chance to offline drop those tablespaces and, hopefully, be able to import them back, if those are transportable tablespaces, and the metadata dump file is still available. Another idea would be to offline datafiles and then online them after OPEN RESETLOGS. Should someone try that -- let us know if it works.

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?