Data Guard Broker - Oracle 11g

Numerous enhancements have been made to Data Guard Broker. Data Guard Broker simplifies the management of the physical and logical standby databases by providing an easy-to-use command-line interface. The amount of learning curve associated with Data Guard Broker syntax is significantly less than learning the Data Guard initialization parameters and syntax required to maintain Data Guard.

Note We recommend that customers leverage Data Guard Broker to maintain the Data Guard configuration. Once you set up the environment to leverage the features of Data Guard, it is a committed relationship. It is an all-or-nothing model. You cannot maintain just the portions of the Data Guard infrastructure using Data Guard Broker and yet continue to modify the initialization parameters manually using SQL*Plus

Unfortunately, Data Guard Broker setup features are not available in Database Console. You must implement the Enterprise Manager Grid Control that requires an Oracle Management Server and Grid Control repository. For high-availability considerations, Oracle recommends separating the management server from the database repository.

Data Guard Broker Command-Line Interface

As mentioned previously, one of the new features in Data Guard is the ability to convert a physical standby database to a snapshot standby database. The broker also has the ability to convert a physical standby database to a snapshot standby database with ease. Data Guard Broker can convert a physical standby database to a snapshot standby database with just one command. At this point, you can utilize the database to perform tests such as a QA load test or other activities that require read/write access to the database. Once such tasks are complete, the database can be reverted to physical standby managed recovery mode. Data Guard Broker again can bring the database back to a physical standby database with just one command.

Oracle cannot make the physical standby to snapshot standby conversion easier. The syntax to convert the physical database to a snapshot standby is as follows:

convert database db_unique_name to snapshot standby;

Here you will see a single convert statement that will convert a physical standby to a snapshot standby:

DBA11gDR $ dgmgrl sys/oracle@dba11g
Welcome to DGMGRL, type "help" for information.
Connected.

DGMGRL> convert database 'dba11gdr' to snapshot standby;

Converting database "dba11gdr" to a Snapshot Standby database, please wait... Database "dba11gdr" converted successfullyBelieve it or not, that was it! Now, let’s put the snapshot standby back to a physical standby database. Again, it takes only a single convert statement to put it back. Here you will see a single convert statement that will convert a snapshot standby into a physical standby:

DGMGRL> convert database 'dba11gdr' to physical standby;

Converting database "dba11gdr" to a Physical Standby database, please wait...
Operation requires shutdown of instance "DBA11gDR" on database "dba11gdr"
Shutting down instance "DBA11gDR"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "DBA11gDR" on database "dba11gdr"
Starting instance "DBA11gDR"...
ORACLE instance started.
Database mounted.
Continuing to convert database "dba11gdr" ...
Operation requires shutdown of instance "DBA11gDR" on database "dba11gdr"
Shutting down instance "DBA11gDR"...
ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.
Operation requires startup of instance "DBA11gDR" on database "dba11gdr"
Starting instance "DBA11gDR"...
ORACLE instance started.
Database mounted.
Database "dba11gdr" converted successfully

We just demonstrated how executing the new convert database to physical/snapshot standby command transforms a physical standby database into a read/write database. Other commands that are new to the Data Guard command-line interface are disable fast_start failover, enable fast_start failover, and show fast_start failover. These new commandline options are discussed in further detail in the following sections.

Unfortunately, the Data Guard Manager does not have the ability to convert a physical standby database to a real-time query standby database. You must use SQL*Plus to convert the physical standby to a real-time query standby database. The feature to convert a physical standby database to a real-time query standby database will be available in Oracle Enterprise Manager Grid Control 11g when it is released.

Using Data Guard Broker simplifies the management of the redo transport and apply layer in Oracle Database 11g. The logic is that the primary database will be in transport-on or transport-off mode. This is an attribute of the LogShipping property and corresponds to the log_archive_dest_state_n initialization parameter. transport-off will indicate that this parameter is being set to defer, whereas transport-on will set this parameter to enable. The same logic applies to the physical standby database. The physical standby database will either be in apply-on or apply-off mode.

Customize Fast-Start Failover Events

Oracle Database 11g Data Guard Broker introduces numerous enhancements to the Data Guard Manager command-line interface. Enhancements include the ability to customize what initiates the fast-start failover conditions. Prior to Oracle Database 11g, the fast-start failover conditions were induced by database health checks provided by Oracle. Now, the fast-start failover can be induced by certain configurable conditions. For example, the fast-restart failover process can be initiated when the primary database archivelog destination runs out of space by setting the fast_start_failover condition to the value of Stuck Archiver:

DGMGRL> enable fast_start failover condition "Stuck Archiver"
Succeeded.

Alternatively, you can enable the fast_start failover condition for a specified ORA- error message. Although you would never want to fail over from just an ORA-600 error message, the following example is provided to demonstrate the ease of specifying a generic ORA-600 error condition:

DGMGRL> enable fast_start failover condition 600; Succeeded.

If you issue the new show fast_start failover status command in Data Guard Broker, it reports that the ORA-600 error will initiate a failover:

DGMGRL> show fast_start failover;

Fast-Start Failover: ENABLED
Threshold: 45 seconds
Target: dba11g
Observer: bpo40.dbaexpert.com
Lag Limit: 30 seconds
Shutdown Primary: FALSE
Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver YES
Datafile Offline YES

Oracle Error Conditions:

ORA-00600: internal error code, arguments:
[%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]

Now, the show configuration verbose command also displays fast-start failover–related information.

Tip DBAs often get surprised when they realize that commands to DGMGRL can also be scripted. DBAs can issue commands in the command-line interface by invoking dgmgrl in Unix similar to what is shown here:

DBA11g $ dgmgrl sys/oracle "edit database 'dba11g'
set property faststartfailovertarget='DBA11gDR';"
DGMGRL for Linux: Version 11.1.0.4.0 - Beta
Copyright (c) 2000, 2005, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected.
Property "faststartfailovertarget" updated
dgmgrl sys/oracle "edit database 'dba11gdr'
set property faststartfailovertarget='DBA11g';"

Initiate Fast-Start Failover from Applications

Oracle Database 11g also introduces the new DBMS_DG PL/SQL package, which can be customized by applications to initiate a request for fast-start failover of the primary database. Data Guard Broker will perform some preliminary validations such as checking the readiness of the failover state or checking that the lag limit is within the threshold on the primary database and communicates with the observer to initiate a failover. If no parameters are specified, the default string of “Application Failover Requested” will be logged in the broker log file and in the database alert log file. You can see from the function description here that the function expects a condition string for the fast-start failover:

SQL> desc dbms_dg

FUNCTION INITIATE_FS_FAILOVER RETURNS BINARY_INTEGER
Argument Name Type In/Out Default?
------------------- ------------- ---------------
CONDSTR VARCHAR2 IN

This function can return any one of the following return codes:

  • ORA-00000: Normal, successful completion.
  • ORA-16646: Fast-start failover is disabled.
  • ORA-16666: Unable to initiate fast-start failover on a standby database.
  • ORA-16817: Unsynchronized fast-start failover configuration.
  • ORA-16819: Fast-start failover observer not started.
  • ORA-16820: Fast-start failover observer is no longer observing this database.
  • ORA-16829: Fast-start failover configuration is lagging.

You can query the V$FS_FAILOVER_STATS dynamic view on the primary database to obtain the cause of failure information and when it occurred, as shown here:

select last_failover_time, last_failover_reason from v$fs_failover_stats;

New Data Guard Manager Properties

In addition to the RedoCompression property, there are new Data Guard Manager properties worth mentioning, as shown in Table.

New Data Guard Manager Properties

There are new values for the FS_FAILOVER_STATUS column in the V$DATABASE dynamic view for fast-start-enabled databases. The valid values for this column are as follows:

  • tag under lag limit
  • tag over lag limit

The tag under lag limit value indicates that the database is valid for fast-start failover. The tag over lag limit value indicates that the database is behind and cannot perform a faststart failover because the standby database apply is behind the FastStartFailoverLagLimit property.

Detect Lost-Write Conditions Using a Physical Standby

Most everyone will agree that the highest priority of a DBA is to protect the data. DBAs are constantly architecting and rearchitecting to find the best solution that will protect the enterprise from faults introduced by the inevitable such as block corruptions, lost writes, and failed disks. Previously, DBAs were only able to architect database resilience strategies to protect against lost-write failures using third-party hardware solutions. Oracle Database 11g Data Guard provides a mechanism to detect lost-write failures on the physical standby. With the proper architecture including the flashback recovery area, the database can recover from these lost-write faults.

First, let’s discuss what lost-write failures are. A lost write can occur for several reasons. The most common reason is when the SAN disk array receives an acknowledgment for a successful disk block write to disk when it really did not. A subsequent read of an allegedly written block will return old content. The physical standby is now able to detect lost-write block corruptions by comparing SCNs of the redo blocks on the primary database and SCNs of the blocks on the physical standby database. Oracle Data Guard detects a lost-write corruption when the primary database block SCN is lower than the standby database block SCN.

There are steps for recovery when lost-write corruption is detected from the physical standby database. In addition, it is assumed that all the data contained on the corrupted lostwrite block will be lost. When such errors are detected on the standby (ORA-00752) database, you must fail over to the physical standby:

SQL> alter database activate standby database;

DBAs must also realize that the old primary database must be completely rebuilt. The old primary database can no longer participate in a Data Guard configuration. The traditional options such as flashing back the database or reinstating the database are not an option when dealing with lost-write detection errors.

Support of Heterogeneous OS Data Guard Configuration

Oracle Database 11g Data Guard now lifts the same OS requirements for a Data Guard configuration.The initial deployment of this heterogeneous Data Guard configuration is limited in scope. Effective with Oracle Database 11g, the Data Guard configuration can be composed of a hybrid of Linux and Windows primary and standby. Previously in Oracle Database10g, different combinations such as HP-UX PA-RISC and Itanium platforms were supported for the heterogeneous Data Guard configuration. For a table of different platform combinations supported by Data Guard, please refer to MetaLink note 413484.1, “Data Guard Support for Heterogeneous Primary and Standby Systems in Same Data Guard Configuration.”

Oracle Database 11g Data Guard Over Storage Vendor Solutions

A lot of customers build high-availability solutions using storage vendor technologies. Solutions are typically supplied by third-party companies that provide business continuity using some sort of sync and split technologies. For example, as a file system is added to the primary database, the Business Continuity Volumes (EMC solution) or Shadow Images (Hitachi solution) can be added on both the primary and disaster recovery site to continue this traditional high-availability block for block data replication. EMC provides Data Guard–equivalent solutions using TimeFinder. Hitachi provides similar equivalency through TruCopy. Moreover, Network Appliance has a similar technology called SnapMirror for Oracle that performs pointerbased block replication to the disaster recovery site.

Oracle’s Data Guard is comparable or even better than the storage vendor’s snapshot technologies. With the new real-time query and snapshot standby technologies, DBAs should definitely consider Data Guard options over hardware-level HA technologies. Oracle’s goal is to provide these similar technologies as a native option to the Enterprise Edition. Oracle Database 11g provides real-time query and snapshot standby database features in addition to providing disaster recovery while using a single copy of the storage.


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

Oracle 11g Topics