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)
  • DB_BLOCK_CHECKING is set to FULL.
  • DB_LOST_WRITE_PROTECT is set to TYPICAL.
  • DB_BLOCK_CHECKSUM is set to FULL.
DATA_ONLY
  • DB_BLOCK_CHECKING is set to MEDIUM.
  • DB_LOST_WRITE_PROTECT is set to TYPICAL.
  • DB_BLOCK_CHECKSUM is set to FULL.

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:  

  1. Set the DB_ULTRA_SAFE=DATA_AND_INDEX initialization parameter using:
  2. SQL> alter system set db_ultra_safe=dta_and_index scope=spfile;
  3. SQL> shutdown immediate (Shutdown your Database)
  4. SQL> startup (This will start your primary Database using your new parameter set in the SPFILE previously)

On the Physical Standby Database: 

  1. Set the DB_ULTRA_SAFE=DATA_AND_INDEX initialization parameter using:
  2. SQL> alter system set db_ultra_safe=dta_and_index scope=spfile;
  3. SQL> startup nomount
  4. SQL> alter database mount standby database;
  5. 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: 

  1. SQL> alter database recover managed standby database cancel;
  2. 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: 

  1. 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:

Screen 1

Example done at the Standby:

Screen 2

Technorati Tags: ,,,

5 thoughts on “DB_ULTRA_SAFE a new GEM for High Availability

  1. Hi Francisco,

    When I saw the automatic repair of block corruption of a primary db from a standby (or indeed from the primary to the standby) I thought that was an outstanding new feature.

    My understanding was though, that the automatic repair of block corruption required active dataguard? I don’t know what technical restriction (if indeed there is one) that requires this, but I thought you needed the database open read-only and performing media recovery for the automatic block detection.

    jason.

  2. Hello Francisco, an excellent article on this DB_ULTRA_SAFE and seems a feature that ensures greater security and availability of data and therefore also provides greater versatility and security for the End User that your business will be supported with leading-edge technologies.
    Congratulations.

  3. Dear Jason,

    Automatic repair of bloc corruption only works with 11gR2, and it works with normal Standby Databases and Active Data Guard (I have it working on both enviroments), previously with 11gR1 only prevent and detect mode was available.

    I hope this answer your question :)

    Kind Regards,

    Francisco Munoz Alvarez

  4. Pingback: DEFERRED_SEGMENT_CREATION and DB_ULTRA_SAFE Parameters (New to 11gr2) « Oracle 'Ant'

Leave a Reply