Pythian - Love your data

RMAN: Corrupt block … let’s re-read … nope it all good

Nov 8, 2012 / By Yury Velikanov

Tags: ,

Just received a page about “Corrupt block”. From the first look it kind of scary to receive such page 40 minutes before your shift ends. Right?
After examining an alert.log (see below) and looking through knowledge bases found an explanation that it isn’t as bad as I thought. I liked the explanation I found therefore I decided to share it with rest of the world.
Here you go folks

ALERT.LOG
...
Wed Nov  7 23:34:35 2012
Hex dump of (file 55, block 742286) in trace file /u01/db/tech_st/10.2.0/admin/PRDB_host/udump/PRDB_ora_10778.trc
Corrupt block relative dba: 0x0dcb538e (file 55, block 742286)
Fractured block found during backing up datafile
Data in bad block:
 type: 6 format: 2 rdba: 0x0dcb538e
 last change scn: 0x002c.5c0523dc seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xc0b10601
 check value in block header: 0xafaf
 computed block checksum: 0xe36e
Reread of blocknum=742286, file=/u01/oradata/apps_index_9.dbf. found valid data
Wed Nov  7 23:39:11 2012
...

And a Support analyst says:

Looking at the error looks like your Rman backups are running when the error was reported.
Say Rman has read the first 8 OS blocks and by the time it comes to read the remaining 8 OS blocks of 8K oracle block it see's block has been modified by some server process.
Now since first 8 blocks are from different SCN and next 8 OS blocks of the same oracle blocks are at different SCN Rman cannot back up the block as its fractured.
So it will again retry and try to get a consistent copy (Not read consistent but block having head and tail information same) and went it finds it gives message found valid data.

Please note Rman tries to backup a consistent image of the block(Head and tail portion of the block should match). Oracle blocks are made of 0S blocks.One 8 k block is made of 16 (512 bytes) OS blocks.

So if Rman is unable to get a consistent image of the block it would report errors saying found fractured block while trying to backup that block. Rman would however retry again and see if its now able to get the consistent image of the block .

Clearly in your case we can see it has found a valid block.

Please note it's recommended to run the Rman backup when the load on the database is less.

If the block that rman wants to backup is been modified quite frequently then rman wouldn't be able to get a consistent image of the block.

It kind of nice explanation right? I learned something today. And end of the day my shift finished well :)
Have a good shift folks :)

6 comments on “RMAN: Corrupt block … let’s re-read … nope it all good”

  1. Charlie ?? (@mujiang) on said:

    Hi Yury,

    Nice talking to you on your SQL v.s. srvctl blog. Though I didn’t hear any feedback from Christo Kutrovsky, the blog author of OPT_ESTIMATE hint: Usage Guide. :)

    May I bravely ask you to share one of your (RMAN) backup and recovery presentation slides? So I could save my time and use it to share knowledge with some other DBAs.

    Thanks and enjoy the rest after a good shift,
    Charlie

  2. Saurabh Manroy on said:

    Similarly, while validating a datafile using DBV, DBV also increments the number against “# of Influx blocks” in its report when it re-reads a valid block which was found fractured during first read.

  3. Saurabh Manroy on said:

    Similarly, while validating a datafile using DBV, DBV also increments the number against “# of Influx blocks” in its report when it re-reads a block which was found fractured during first read.

  4. Yury Velikanov on said:

    Hey Saurabh,

    You can find my RMAN and other presentations under SlideShare.
    http://www.slideshare.net/yvelikanov/10-problems-with-your-rman-backup-script

    Enjoy,
    Yury

  5. Alexey Maksimov on said:

    Well, that’s all good, I had another question though – if it’s possible to suppress these warnings. They are noise and should be ignored, but our monitoring system goes off on them. I think there is a retry count and if RMAN hits it, another message is printed (need to check, not sure at the moment).

    Any ideas of hidden parameters etc that can suppress these fractured block warnings during RMAN backups?

    Thanks.

  6. Yury Velikanov on said:

    >> Any ideas of hidden parameters etc that can suppress these fractured block warnings during RMAN backups?

    We have adjusted our monitoring to ignore the errors if it confirmed that reread works. I would suggest look on how to adjust your monitoring to ignore those too.

    I wouldn’t expect Oracle to have any hidden parameter for disabling those messages. I would like to be wrong and if someone knows the way please feel free to contribute :)

Leave a Reply