DB_ULTRA_SAFE a new GEM for High Availability
DB_ULTRA_SAFE is a new parameter introduced with Oracle 11gR1, and a fantastic new GEM for High Availability, that using Data Guard to configure on both the primary and standby will trigger the most comprehensive data corruption prevention and detection (and repair on 11gR2, see **) tool in the market.
** Starting in Oracle Database 11g Release 2 (11.2), the primary database automatically attempts to repair the corrupted block in real time by fetching a good version of the same block from a physical standby database.
Speaking simple, what this new functionality will do is use your Standby Database as a backup to correct automatically any data corruption on your primary database and vice-versa (again on 11.2).
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.
You basically need to understand that when setting DB_ULTRA_SAFE it will control the behaviour of DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, or DB_LOST_WRITE_PROTECT parameters for you, which mean:
| When you set DB_ULTRA_SAFE to | Then the following parameters… |
| DATA_AND_INDEX (recommended by Oracle) |
|
| DATA_ONLY |
|
Lets’ Check all the parameters affected by DB_ULTRA_SAFE:
DB_BLOCK_CHECKING(Introduced with Oracle 8.1.6) prevents memory and data corruptions, but it incurs some performance overhead on every block change.DB_BLOCK_CHECKSUM(Introduced with Oracle 8.1.6) detects redo and data block corruptions and detect corruptions on the primary database and protect the standby database. This parameter requires minimal CPU resources.DB_LOST_WRITE_PROTECT(also introduced with 11gR1) enable or disable a physical standby database to detect lost write corruptions on both the primary and physical standby database.
Important: 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.
To activate it, all you need to do is follow the following steps:
On the Primary Database:
- Set the DB_ULTRA_SAFE=DATA_AND_INDEX initialization parameter using:
- SQL> alter system set db_ultra_safe=dta_and_index scope=spfile;
- SQL> shutdown immediate (Shutdown your Database)
- SQL> startup (This will start your primary Database using your new parameter set in the SPFILE previously)
On the Physical Standby Database:
- Set the DB_ULTRA_SAFE=DATA_AND_INDEX initialization parameter using:
- SQL> alter system set db_ultra_safe=dta_and_index scope=spfile;
- SQL> startup nomount
- SQL> alter database mount standby database;
- SQL> alter database recover managed standby database disconnect from session;
If you are using your Standby Database on Read Only mode you also need to run the follow commands on your Physical Standby DB:
- SQL> alter database recover managed standby database cancel;
- SQL> alter database open read only;
If you decide to change later the Read Only Standby to Standby again, you just will need to run the following command:
- SQL> alter database recover managed standby database disconnect from session;
Hoping this information could help you in the future,
Francisco Munoz Alvarez
Example done on primary:
Example done at the Standby:
Technorati Tags: DB_ULTRA_SAFE,HIGH AVAILABILITY,BLOCK CORRUPTION,DATA CORRUPTION
