Here some lines explain about the header of a block. Normally we know have seen block corrupt but what if when the first block of a datafile containing the datafile header becomes corrupt. The header of a block contains information like the type of segment the block belongs to and the SCN of the last transaction that modified that block. For a more advanced description. The v$ views are actually structures stored in RAM.  The v$datafile view contains details about each database, but the v$datafile_header contains important space management information that applies to all data files within the header. Now have some knowledge about those steps which are used by DBA to perform a recovery when the first block of a datafile containing the datafile header becomes corrupt. 

Let’s simulate this scenario using the following dd command:

To check and have a completed list of corrupt blocks as we have already seen we should issue a backup validate command:

The V$DATABASE_BLOCK_CORRUPTION view as usual should contain data about which blocks are corrupt, but it doesn’t show any rows:

What does it happen if I try to recover that first block ? It seems to work fine…

… but trying again a backup validate command I obtain the same error.

Ok, it’s time to perform a more familiar restore/recover tablespace operation.
So a typical sequence is put that tablespace offline, restore it, recover it and then put it back online:

Oops… the familiar restore/recover sequence is not working at all.
And I can’t even put the tablespace online again.

It seems the familiar restore/recover operation cannot start because of the corrupt data block number 1.
So how can I proceed ? I put again the tablespace offline

… and simply removed the entire datafile with the corrupt data block number 1.

Without the entire datafile, the restore tablespace command is able to complete successfully.

Also the recover tablespace command is able to finish its operation.

The tablespace should be now available again to all the users.

Ok… It’s not true and I know why.

During the restore operation RMAN simply used the first available backup piece: o1_mf_nnndf_TAG20130318T224952_8nhz414b_.bkp. But that backup piece contains a datafile with few corrupt data blocks because I forced to skip them during the backup operation. You can verify what I’m saying here in one of my previous posts.

Let’s update the V$DATABASE_BLOCK_CORRUPTION view issuing a backup validate command.

As you can see datafile number 11 has few corrupt blocks.

Using the recover corruption list we are able to correct the content of those corrupt blocks.
Just note also how RMAN “failover to the previous backup” (skipping the already mentioned o1_mf_nnndf_TAG20130318T224952_8nhz414b_.bkp backup piece and also the next available one, o1_mf_nnndf_TAG20130318T090132_8ngglx76_.bkp) because using the current backup piece is not able to perform and complete the recovery operation.

RMAN after looking into o1_mf_nnndf_TAG20130318T072836_8ng94o0k_.bkp backup piece completes the recovery operation and the T1 table is now really available to all the users.

Thank you for giving your valuable time to read the above information.


For More Detail , You can join us follow:

LinkedIn Group: Oracle Cloud DBAAS

Facebook Page: OracleHelp

About The Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.