Improvements in Handling Data Corruption - Oracle 11g

Oracle Database 11g provides several new innovations that help catch inci dents of data corruption before they mushroom into major problems.These include the new integrated mechanism for data corruption checking through the use of the new initialization parameter db_ultra_ safe and lost-write detection through the use of a standby data base.We discuss these and other data corruption–related new features in the following sections.

Protecting the Database from Data Corruption

In previous releases of the Oracle database, you had to employ initiali- zation parameters such as db_block_checking and db_block_ checksum to check for various types of data corruption.However, these parameters operated inde pen- dently of each other,and there was no overall mechanism to control data base corruption.Oracle Database 11g provides the new initialization para meter db_ultra_safe to offer better protection against data corruption.This parameter lets you proactively detect data corruption,thus enhancing the high-availability capabilities of the Oracle database.

In Oracle Data base 11g,it takes less time to discover block corruptions, because several database components and utilities are capable of detecting and recording corrupt data blocks in the V$DATABASE_BLOCK_CORRUPTION view.The database maintains an accurate tally of the block corru- ptions in the data base by updating this view as appropriate when data block corruption is detected and when the corrupt blocks are repaired.

You still use the db_block_checking and db_block_checksum initialization parameters in the Oracle Database 11g release,but now you can use the db_ult ra_safe initialization parameter to control the setting of these two para meters in order to provide a consistent data protection mechanism.In addition to these two parameters.The db_ultra_safe para meter also controls the setting of the new db_lost_write_protect initialization para meter. Further more, the db_ultra_ safe parameter controls other types of data prot- ection behavior in the data base,such as requiring automatic storage manage ment(ASM) to perform sequential mirror writes.

The db_ultra_safe initialization parameter offers flexibility by allowing you to set various levels of protection from data corruption.

Lost-Write Detection Using a Physical Stand by Database

Occasionally,your database may signal the completion of a block write be fore the write is actually stored on disk,because of the malfunctioning of the storage hardware or software.This is known commonly as the lost-write form of data corruption.Oracle Database 11g provides a new initialization parameter called db_lost_ write_ protect,which lets you use a physical standby database to detect data corruption due to a lost-write form of data corruption.If you’re already using a physical standby database for any reason,you can now leverage your efforts in maintaining that standby database by letting it perform a comprehe nsive lost-write data corruption detection.

If you set the value of the db_lost_write_protect parameter to typical (the default value),the instance will log all buffer cache block reads in the redo log files for all read/write table spaces.However,to enable the recording of all reads including read-only tablespaces,you need to set the value of the db_lost_ write_protect parameter to full instead of the default value of typical.

The lost-write protection feature works best in a Data Guard environ ment, where you set the db_lost_write_protect parameter in both the primary data base and the standby data base.During the application of redo while per forming a managed recovery.The stand by database detects lost writes on the primary database when the block SCNs on the primary database are found to be lower than the SCNs on the standby data base.If,on the other hand,the SCN on the primary data base is higher than that on the standby data base,there is a lost write on the stand by data base.Repairing the standby database lost writes entails the re-creation of the entire standby database or just the affected files.

You can encounter a lost write during the normal database operation or during a media recovery.To generate the lost-write error that occurs during normal operation,you must recover the data base(or the tablespace)to the SCN when the stale block read corruption occurred.If you encounter a lost-write error during a media recovery,you must open the database with the resetlogs option,thus losing all data after the resetlogs SCN.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Oracle 11g Topics