The database has remained up despite a corrupt OS datafile. The net effect is my usable backups are days old as I did not catch this rightaway. I want a full RMAN backup but there is a single block that keeps hanging it up. I tracked it down to a single row in a table with 2 CLOB's. I have since been able to CTAS where id <> badrow, I fixed the bad rows so that I can CTAS all rows. I can now EXP the table and have an EXP of the entire Database transferred to another machine.
If I instruct RMAN to accept a corruption and continue does this mean it will fail to restore properly on the other machine? I thought rman did not backup unused blocks so I am a little confused about why it is still trying to back this one up.
unix cp datafile fails
EXP is able to backup the database. Here is the RMAN bomb without attempting
set maxcorrupt for datafile 5 to 10;
channel Ch_1: starting piece 1 at 01-APR-04
channel Ch_1: finished piece 1 at 01-APR-04
piece handle=/ora/backup/blprod/backup/BLPROD_20040401_2211_1_dbf.bak comment=NONE
channel Ch_1: starting piece 2 at 01-APR-04
channel Ch_1: finished piece 2 at 01-APR-04
piece handle=/ora/backup/blprod/backup/BLPROD_20040401_2211_2_dbf.bak comment=NONE
channel Ch_1: starting piece 3 at 01-APR-04
released channel: Ch_1
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-03009: failure of backup command on Ch_1 channel at 04/01/2004 10:28:48
ORA-19501: read error on file "/ora/data/blprod/jupiterd_m01.dbf", blockno 72193 (blocksize=8192)
ORA-27063: skgfospo: number of bytes read/written is incorrect
Additional information: 81920
Additional information: 524288
Anyway to find objects still using block 72193 and do some more surgery?
Another idea - The most obvious solution is to use the old backup, restore it and then roll forward all of the archive logs, I was getting archive log write errors and could not tell if they were related to the standby or more local disk problems. But that should not preclude looking into it as that is a backup before the corruption. As long as I have the logs I should be ok.
Run dbv on the datafile and find out how serious the damage is. If only few objects affcted, you can rebuild indexes or move tables. If the file has many corrupt blocks then resotre it from a good backup and recover.
Oracle Certified Professional 8i, 9i.
"The degree of normality in a database is inversely proportional to that of its DBA"