Oracle 11g Data Guard: Grid Control Management
June 25, 2009
Synopsis. The Data Guard feature set has been expanded dramatically in Oracle Database 11g to make it even easier for an Oracle DBA to control and monitor any complex, multi-database disaster recovery environment. This article the third in this ongoing series demonstrates how to extend an existing Data Guard Broker configuration into an Oracle 10g Enterprise Manager Grid Control environment as well as how to configure the appropriate level of data protection between Oracle 11g primary and standby databases.
The prior article in this series explored how to use Oracle 11gs Data Guard Broker (DGB) utilities to configure, monitor, and maintain relationships between the two database environments. This article will discuss how to:
Data Protection Modes
Before I demonstrate how to perform role transitions using Enterprise Manager Grid Control, its 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. Its 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 databases 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 doesnt have to wait for acknowledgment of the transactions committal. This is a viable option so long as theres 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 databases local online redo log as well as at least one standby databases 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 thats 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 Ill 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, Ill 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 consoles Targets:Databases panel displayed them as valid targets:
To access the Data Guard configuration for my primary and standby databases, Ill 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, Im presented with current status of the Data Guard environment, as shown in Figure 3-13.