The prior article in this series explored how to use Oracle 11g’s Data Guard Broker (DGB) utilities to configure, monitor, and maintain relationships between the two database environments. This article will discuss how to:

• Configure data protection modes between the primary and standby databases
• Set up Oracle Enterprise Manager Grid Control for management of a Data Guard environment
• Perform role transitions using Oracle Enterprise Manager Grid Control

Data Protection Modes

Before I demonstrate how to perform role transitions using Enterprise Manager Grid Control, it’s an appropriate time to review how Oracle 11g Data Guard balances redo log application synchronicity versus safety to guarantee the appropriate level of data protection, availability, and performance for both the primary database and its standby database(s). Oracle 11g offers three different modes of data protection:

Maximum Performance Mode. When a company is willing to trade the need for immediate transaction recoverability on the standby database for the best possible performance of the primary database, this is probably an appropriate choice – for example, in the case of a decision support or moderate OLTP environment. It’s also the default data protection mode, and it allows Oracle 11g to commit a transaction as soon as the redo for that transaction has been written to the primary database’s local online redo log. Of course, these transactions are eventually written to the standby database(s) as well, but since they are written asynchronously, the primary database doesn’t have to wait for acknowledgment of the transactions’ committal. This is a viable option so long as there’s sufficient network bandwidth between the primary and standby database(s).

Maximum Availability Mode. A company or organization may decide that at least some primary database performance can be sacrificed in favor of improved transaction recoverability on the standby databases. This next level of data protection offers a compromise because it insures that a transaction is not considered as committed until its redo log entries have been written to the primary database’s local online redo log as well as at least one standby database’s standby redo log. The primary database stays active at all times even if the transmission of redo log data is disrupted temporarily to the standby database because Data Guard will continue to attempt the transmission to the standby until all redo “gaps” are resolved satisfactorily. This is the most viable option when the performance of the primary database needs to be balanced against the secure knowledge that redo synchronization will eventually take place – for example, an internet-based customer order placement system.

Maximum Protection Mode. When an organization needs to insure that not even one byte of committed data can ever be lost, this is the only appropriate mode because it provides the most extreme protection against any data loss … at a cost. Data Guard will insure that no data loss occurs even if the primary database itself should fail because it insures that all redo has been written to the local online redo log as well as the standby redo log of at least one standby database in the Data Guard configuration and, if it cannot satisfy this request, it will automatically shut down the primary database to insure no additional transactions will be accepted. Therefore, to prevent the primary database from shutting down unexpectedly, Oracle recommends configuring at least two standby databases. This option is almost certainly required for financial systems in which complex commodity or equity transactions must absolutely be guaranteed.

The appropriate data protection mode is directly influenced by the redo transport mode that’s been specified for the Data Guard configuration. Table 3.1 below summarizes the combined impact of these settings.

Since my major focus in this article series is concentrated upon quicker demonstrations of the various Oracle 11g Data Guard features, for now I’ll leave my Data Guard data protection mode at the default level of maximum performance. However, I promise to return to this topic when I discuss the benefits of implementing Data Guard in a Real Application Cluster (RAC) environment in the final articles in this series.

Configuring EM Grid Control Agents

Before I can demonstrate how to perform switchover or switchback operations with Grid Control, I’ll need to install and configure an appropriate Grid Control agent on both hosts. To accommodate this, I first installed version 10.2.0.1 Oracle Enterprise Manager Grid Control agents on the primary and standby hosts using Oracle Universal Installer. I then applied patch set #3731593 to the Grid Control agents on both hosts to upgrade them to version 10.2.0.4. This permitted my existing Oracle 10.2.0.4 Grid Control infrastructure to partake in their management. Once the agents were successfully started and my Grid Control Oracle Management Server (OMS) was able to communicate with them, the Enterprise Manager Grid Control console’s Targets:Databases panel displayed them as valid targets:

To access the Data Guard configuration for my primary and standby databases, I’ll connect to my primary database and navigate to its Maintenance tab, as shown in Figure 3-12 below.

Once I select the Setup and Manage link from the Data Guard section from the Maintenance tab, I’m presented with current status of the Data Guard environment, as shown in Figure 3-13.

Verifying the Data Guard Configuration

Grid Control also allows me to easily verify the existing Data Guard environment with one simple mouse click. By selecting the Verify Configuration link under the Additional Administration section near the bottom of the Data Guard panel shown in Figure 3-13 previously, Grid Control initiates a complete verification of the current Data Guard “stack”:

Once the verification is complete, Grid Control details its findings in a report, as well as offering suggestions for configuration of standby redo logging to insure the highest level of data protection, as shown in Figure 3-22 below:

Finally, here’s the complete text of the verification report I created against my current Data Guard environment using Grid Control:

Initializing
Connected to instance 11gPrimary:orcl
Starting alert log monitor...
Updating Data Guard link on database homepage...

Data Protection Settings:
  Protection mode : Maximum Performance
  Log Transport Mode settings:
    primary_db: ASYNC
    stdby_db: ASYNC
  Checking standby redo log files.....Done
   (Standby redo log files needed : 1)

Checking Data Guard status
  primary_db : Normal
  stdby_db : Normal
Checking Inconsistent Properties

Checking agent status
  primary_db ... OK
  stdby_db ... OK

Switching log file 162.Done
  Checking applied log on primary_db.......WARNING: 
Timed out after 60 seconds waiting for log to be applied.

Processing completed.

Performing Switchover Using EM Grid Control

Now that my Grid Control environment is configured and established, I’ll demonstrate how to perform the same switchover and switchback operations that I illustrated in the prior article via Data Guard Broker’s command line tool, DGMGRL. From the Data Guard Configuration panel (see Figure 3-13) I’ll select my standby database, stdby_db, as the target of the switchover operation and then click the Switchover button. Grid Control next asks me to confirm my intentions, as shown in Figure 3-31:

Once I confirm the switchover operation, Grid Control tracks the operation’s progress until it’s successfully completed, as shown in Figure 3-32:

After a few minutes, Grid Control confirms the successful transition between primary and standby databases. This is reflected in the information presented in Figure 3-33. Notice that the two databases have indeed reverted to their originally assigned roles:

I’ve captured the edited alert logs of the primary and standby databases in Listing 3.1 to confirm the successful switchover operation.

Performing Switchback Using EM Grid Control

Performing a switchback operation is also simple using Grid Control. Now that I’ve successfully completed the switchover operation, I’ll initiate a switchback operation as shown in Figure 3-41 below:

This time around, however, note that I’ll select my original primary database (primary_db) as the target of the switchback operation and then click the Switchover button. Grid Control once again asks me to confirm my intentions, as shown in Figure 3-42:

Once a few moments have elapsed, Grid Control once again confirms the successful transition between the original standby (now fulfilling the standby role once again) and the original primary (also now fulfilling the primary role again). This is reflected in the information presented in Figure 3-43:

The results of the successful switchback operation are confirmed in the edited alert logs of the primary and standby databases as shown in Listing 3.2.

Next Steps

In the next article in this series, I’ll explore how to:

• Use a recovery catalog to catalog backups made on the standby database
• Implement block change tracking on a standby database
• Create incrementally updateable image copy backups from a standby database

References and Additional Reading

While I’m hopeful that I’ve given you a thorough grounding in the technical aspects of the features I’ve discussed in this article, I’m also sure that there may be better documentation available since it’s been published. I therefore strongly suggest that you take a close look at the corresponding Oracle documentation on these features to obtain crystal-clear understanding before attempting to implement them in a production environment. Please note that I’ve drawn upon the following Oracle Database 10g and 11g documentation for the deeper technical details of this article:

B28279-02 Oracle Database 11g New Features Guide

B28294-03 Oracle Database 11g Data Guard Concepts and Administration

B28295-03 Oracle Database 11g Data Guard Broker

B28320-01 Oracle Database 11g Reference Guide

B28419-02 Oracle Database 11g PL/SQL Packages and Types Reference

B28832-01 Oracle Database 10g Enterprise Manager Grid Control Agent Download Installation

Also, the following MetaLink documentation was extremely helpful after patching of the Enterprise Manager Grid Control agents was completed and I needed to synchronize the agents on the primary and standby database servers with the contents of the Enterprise Manager Grid Control management repository:

330932.1 Problem - Agent Upload Fails - OMS VERSION NOT CHECKED YET

389528.1 Problem: Agent Upload Fails: OMS VERSION NOT CHECKED YET => nmejcn: Received No Status Header From Repository

Previous   Next

Back to DBAsupport.com