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

Thread: Undo tablespace corruption during RMAN backup

  1. #1
    Join Date
    Oct 2002
    Posts
    807

    Undo tablespace corruption during RMAN backup

    The first time that I tried backing up this database using RMAN, I ran into a corruption issue on the UNDO tablespace. A dbverify detects corruption on the datafile as well. What is strange is that a "backup VALIDATE tablespace UNDO" doesn't indicate any corruption! That is pretty bizzare. Anyone know why?

    Short of dropping the tablespace and recreating it (after addressing any objects that were using the undo), any other suggestions?

    Thanks.


    -------
    backup database output

    channel ch00: specifying datafile(s) in backupset
    input datafile fno=00003 name=/u11/oradata/CRMP/userperson01.dbf
    input datafile fno=00027 name=/u11/oradata/CRMP/userfiscal01.dbf
    input datafile fno=00060 name=/u09/oradata/CRMP/userCDPd.dbf
    input datafile fno=00072 name=/u08/oradata/CRMP/undo03.dbf
    input datafile fno=00002 name=/u10/oradata/CRMP/usercodes01.dbf
    channel ch00: starting piece 1 at 16-SEP-04
    channel ch01: starting incremental level 0 datafile backupset
    channel ch01: specifying datafile(s) in backupset
    input datafile fno=00005 name=/u13/oradata/CRMP/user01a.dbf
    input datafile fno=00028 name=/u05/oradata/CRMP/INDXHEARING01.dbf
    input datafile fno=00061 name=/u14/oradata/CRMP/userCDPe.dbf
    input datafile fno=00073 name=/u08/oradata/CRMP/undo04.dbf
    input datafile fno=00004 name=/u12/oradata/CRMP/tools01.dbf
    channel ch01: starting piece 1 at 16-SEP-04
    released channel: ch00
    released channel: ch01
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03009: failure of backup command on ch00 channel at 09/16/2004 06:33:55
    ORA-19566: exceeded limit of 0 corrupt blocks for file /u08/oradata/CRMP/undo03.dbf

    -----------------

    DBVERIFY output

    DBVERIFY: Release 9.2.0.1.0 - Production on Wed Sep 15 11:57:21 2004

    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

    DBVERIFY - Verification starting : FILE = /u08/oradata/CRMP/undo03.dbf
    Page 105402 is marked corrupt
    ***
    Corrupt block relative dba: 0x12019bba (file 72, block 105402)
    Bad header found during dbv:
    Data in bad block -
    type: 2 format: 2 rdba: 0x0012019b
    last change scn: 0xf500.ba7f7b81 seq: 0x0 flg: 0x02
    consistency value in tail: 0x0981f502
    check value in block header: 0x4d7, block checksum disabled
    spare1: 0x2, spare2: 0x0, spare3: 0xd200
    ***
    Page 105403 is marked corrupt
    ***
    Corrupt block relative dba: 0x12019bbb (file 72, block 105403)
    Bad header found during dbv:
    Data in bad block -
    type: 2 format: 2 rdba: 0x0012019b
    last change scn: 0x2100.bb7f7b82 seq: 0x0 flg: 0x02
    consistency value in tail: 0x80822102
    check value in block header: 0x480, block checksum disabled
    spare1: 0x2, spare2: 0x0, spare3: 0x1600
    ***
    DBVERIFY - Verification complete

    Total Pages Examined : 256000
    Total Pages Processed (Data) : 0
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 0
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 255885
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 112
    Total Pages Marked Corrupt : 2
    Total Pages Influx : 0
    aocdb201:/nbscripts/log>

    ----------------------------

    RMAN - backup VALIDATE output - successful!!

    allocated channel: ch01
    channel ch01: sid=16 devtype=SBT_TAPE
    channel ch01: VERITAS NetBackup for Oracle - Release 4.5GA (00000000)

    Starting backup at 15-SEP-04
    channel ch00: starting full datafile backupset
    channel ch00: specifying datafile(s) in backupset
    input datafile fno=00070 name=/u08/oradata/CRMP/undo01.dbf
    input datafile fno=00072 name=/u08/oradata/CRMP/undo03.dbf
    input datafile fno=00074 name=/u13/oradata/CRMP/undo05.dbf
    channel ch01: starting full datafile backupset
    channel ch01: specifying datafile(s) in backupset
    input datafile fno=00071 name=/u08/oradata/CRMP/undo02.dbf
    input datafile fno=00073 name=/u08/oradata/CRMP/undo04.dbf
    input datafile fno=00083 name=/u13/oradata/CRMP/undo06.dbf
    channel ch00: backup set complete, elapsed time: 00:17:55
    channel ch01: backup set complete, elapsed time: 00:17:55
    Finished backup at 15-SEP-04

  2. #2
    Join Date
    Oct 2002
    Posts
    807
    What is strange is that a "backup VALIDATE tablespace UNDO" doesn't indicate any corruption! That is pretty bizzare. Anyone know why?
    The errors are thrown in the alertlog and v$database_block_corruption. Wonder why they don't simply spit them out to the rman logfile! But that would be too easy wouldn't it.

  3. #3
    Join Date
    Jul 2003
    Posts
    323
    You seem to have got it..after backup validate check:
    In Oracle 8i corruption found with the RMAN validate command is only reported in the alert log. In versions 9i+ you can query the view name v$database_block_corruption to determine what corruption, if any, was found by RMAN. The log files only record the process AFAIK !!

  4. #4
    Join Date
    Aug 2001
    Location
    chennai,bangalore
    Posts
    840
    You can do this while RMAN is taking backup.This has to be set in your RMAN backup script.
    This will check for corrupt blocks in the datafile specified and if its with the limit set then it would continue with the backup

    set maxcorrupt for datafile
    212,1,2 to 200;

    212,1,2 are datafile nos and 200 is the max corrupt blocks that RMAN will check.If the max corrupt blocks exceeds 200 then it will give the same error as below.

    regards
    anandkl
    anandkl

  5. #5
    Join Date
    Oct 2002
    Posts
    807
    Originally posted by anandkl
    If the max corrupt blocks exceeds 200 then it will give the same error as below.
    Yup, I've set max corrupt blocks to get RMAN to continue backing it up.

    What's funny is v$database_block_corruption continues to list corruption on datafiles that don't exist anymore! I've dropped a particular tablespace altogether, yet it lists it!

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