Use Data Guard and Configure the DB_ULTRA_SAFE Initialization Parameter for detects and prevents data block corruptions

Use Data Guard and configure the DB_ULTRA_SAFE initialization parameter on both the primary and standby systems for the most comprehensive data corruption prevention and detection.

·         On the primary database, set the DB_ULTRA_SAFE=DATA_AND_INDEX initialization parameter to prevent and detect data corruptions in a timely manner, and thus provide critical data protection and high availability for the Oracle Database.

The DB_ULTRA_SAFE initialization parameter also controls other data protection behavior in Oracle Database, such as requiring ASM to perform sequential mirror write I/Os.

Table 2-1 describes the values that the DB_ULTRA_SAFE parameter automatically assigns to the DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or DB_LOST_WRITE_PROTECT parameters.

Table 2-1 Parameter Values Set by the DB_ULTRA_SAFE Initialization Parameter

When you set DB_ULTRA_SAFE to ...	Then ...
DATA_AND_INDEX (recommended)	o                                DB_BLOCK_CHECKING is set to FULL. o                                DB_LOST_WRITE_PROTECT is set     to TYPICAL. o                                DB_BLOCK_CHECKSUM is set to FULL.
DATA_ONLY	o                                DB_BLOCK_CHECKING is set to MEDIUM. o                                DB_LOST_WRITE_PROTECT is set to TYPICAL. o                                DB_BLOCK_CHECKSUM is set to FULL.

Note:

When you set the DB_ULTRA_SAFE parameter, it automatically integrates and controls the behavior (described in Table 2-1) of the following initialization parameters:

o        DB_BLOCK_CHECKING detects and prevents data block corruptions.

Block checking prevents memory and data corruptions, but it incurs some performance overhead on every block change. For many applications, the block changes are a small percentage compared to the blocks read (typically less than five percent), so the overall effect of enabling block checking is small.

o        DB_BLOCK_CHECKSUM detects redo and data block corruptions and can prevent most corruptions from happening on the physical standby database.

Redo and data block checksums detect corruptions on the primary database and protect the standby database. This parameter requires minimal CPU resources.

o        DB_LOST_WRITE_PROTECT detects stray and lost writes.

Lost write protection enables a physical standby database to detect lost write corruptions on both the primary and physical standby database.

However, if you explicitly set the DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or DB_LOST_WRITE_PROTECT parameters in the initialization parameter file, then the DB_ULTRA_SAFE parameter has no effect and no changes are made to the parameter values. Thus, if you specify the DB_ULTRA_SAFE parameter, do not explicitly set these underlying parameters.

·         On physical standby databases, specify the DB_BLOCK_CHECKSUM and DB_LOST_WRITE_PROTECT parameters:

o        Set DB_BLOCK_CHECKSUM=FULL

If DB_BLOCK_CHECKSUM is set to FULL, then both disk corruption and in-memory corruption are detected and the block is not written to disk, thus preserving the integrity of the physical standby database. This parameter has minimal effect on Redo Apply performance.

o        Set DB_LOST_WRITE_PROTECT=TYPICAL

Lost write protection prevents corruptions—due to stray or lost writes on the primary—from being propagated and applied to the standby database. Setting this parameter has a negligible effect on the standby database. Moreover, setting the DB_LOST_WRITE_PROTECT initialization parameter is recommended over employing the HARD solution, because HARD does not provide full stray and lost write protection and redo application validation.

·         A standby database is a database that is decoupled from the primary database and on which redo data is checked and verified. Redo Apply and SQL Apply processes perform another layer of validation on the standby database that can detect stray or lost writes and corrupted blocks caused by hardware, software, or network issues. Most of these issues cannot be detected on the primary database or may remain hidden on the primary database for a long period.

·         Enable the DB_BLOCK_CHECKING initialization parameter.

Consider setting the DB_BLOCK_CHECKING parameter only on the primary database. Enabling DB_BLOCK_CHECKING on the standby database incurs a much higher overhead and can dramatically reduce Redo Apply performance. Testing is recommended to measure the effect on your environment.