-
Corrupt datafile stopping RMAN
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
dbverify bombs
rman bombs
EXP is able to backup the database. Here is the RMAN bomb without attempting
run {
set maxcorrupt for datafile 5 to 10;
backup...;
}
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-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
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?
Thanks
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.
Last edited by BJE_DBA; 04-01-2004 at 04:29 PM.
-
Find out what object still in block ...
Find the file_id from dba_data_files ...
sql> select file_id from dba_data_files
where file_name = '"/ora/data/blprod/jupiterd_m01.dbf";
then
sql> SELECT SEGMENT_NAME, SEGMENT_TYPE
FROM DBA_EXTENTS
WHERE FILE_ID = #fromabove
AND 72193 BETWEEN block_id AND block_id + blocks;
HTH
Gregg
-
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.
Sanjay G.
Oracle Certified Professional 8i, 9i.
"The degree of normality in a database is inversely proportional to that of its DBA"
-
Usually this error comes when the mount point is 100% full. Meaning there is no space on disk to make the backup. Did you check that?
Oracle Certified Master
Oracle Certified Professional 6i,8i,9i,10g,11g,12c
email: ocp_9i@yahoo.com
-
So did you check if the disk space is enough?
Oracle Certified Master
Oracle Certified Professional 6i,8i,9i,10g,11g,12c
email: ocp_9i@yahoo.com
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|