DBAsupport.com Forums - Powered by vBulletin
Results 1 to 5 of 5

Thread: Corrupt datafile stopping RMAN

  1. #1
    Join Date
    Jan 2003

    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;

    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?


    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.

  2. #2
    Join Date
    Apr 2003
    South Carolina
    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";


    WHERE FILE_ID = #fromabove
    AND 72193 BETWEEN block_id AND block_id + blocks;


  3. #3
    Join Date
    Feb 2000
    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"

  4. #4
    Join Date
    Jun 2001
    Helsinki. Finland
    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

  5. #5
    Join Date
    Jun 2001
    Helsinki. Finland
    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

Click Here to Expand Forum to Full Width