Data Guard Broker and Clients

---

Let's think back to what we have covered so far. We learned

• How to create both a physical and logical standby

• How to configure log transport services

• How to create standby redo logs

• How to manage both a physical and logical standby

• How to perform role reversals.

When we created a physical or logical standby, we had to configure around 28 parameters. Remember all of the syntax and options associated with DBMS_LOGSTDBY package? Switchover to a single physical standby takes around eight different commands. What if we told you that creating a physical or logical standby was just a matter of a few clicks? How about if we told you that a switchover or failover could be reduced to a single command or push of a button? How can it be, you say? Our reply: the Data Guard broker.

The Data Guard broker is a centralized framework that creates, automates, and manages all aspects of a Data Guard configuration. This broker can be accessed locally or remotely by using either of the two clients: the command-line interface (CLI) or the Data Guard page of the new OEM. Once you are connected, you have the ability to change any attribute of the configuration as well as monitor progress and perform health checks. Truly a wonderful thing!

The three main components of the Data Guard broker are the two interfaces or clients and the Data Guard Monitor process. The Data Guard GUI and CLI interfaces allow you to monitor and manipulate the configuration. The Data Guard Monitor is a background process that exists for each database in the configuration. When you make a change via one of the two interfaces, the DMON process is what interacts with the database to effect the actual change. The DMON process also reports back the health of the configuration. All of the information that the DMON process needs to maintain the configuration is stored in metadata files located in each ORACLE_HOME. As the DMON processes communicate with each other across an Oracle Net link, they replicate any changes to the configuration to all metadata files in all ORACLE_HOMES.

The CLI Interface

Before we start using the CLI, we need to satisfy a few requirements. First, the physical or logical standby must have been created, as the CLI does not have the ability to create a standby (only the Data Guard GUI does). In addition, both the primary and standby databases must have been started with the DG_BROKER_START parameter equal to True (this spawns the DMON process) and be using an spfile.

To spawn the command-line interface, enter the following command at the operating system prompt:

dgmgrl

With our ORACLE_SID and ORACLE_HOME environment variables set for the local primary database, enter the following at the dgmgrl prompt:

DGMGRL> connect sys/Not4U

Now that we are connected, we are ready to create the Data Guard configuration. The first step in creating the configuration is to define the primary database. Once that has been defined and saved, we will create the standby database objects.

DGMGRL> create configuration 'MyDR' as >primary database is 'Orlando' >connect identifier is Orlando_hasun1;

In this command, Orlando is the value of the DB_UNIQUE_NAME and Orlando_hasun1 is the Oracle Net alias.

Once we have been returned to the prompt, we can use the SHOW CONFIGURATION command to view what we have created thus far.

DGMGRL> show configuration

To add a standby database to the configuration, we use the ADD DATABASE command. In the following command, it's important to note that Nashville is the value of the standby DB_UNIQUE_NAME parameter, while Nashville_hasun2 is the Oracle Net alias.

DGMGRL> add database 'Nashville' as >connect identifier is Nashville_hasun2 >maintained as physical; 

So, we have successfully created our Data Guard broker configuration. At this point we start watching the primary and standby databases, waiting for the magic to happen. But nothing is different. What the heck? That's because you have to enable the configuration in order for the broker management to begin. To enable the configuration, use the appropriately named ENABLE CONFIGURATION command.

DGMGRL> enable configuration;

Once our configuration is enabled, we can once again use the SHOW CONFIGURATION command to see the results of all of our hard work.

DGMGRL> show configuration; Configuration   Name:            MyDR   Enabled:         YES   Protection Mode: MaxPerformance   Databases:     Orlando   - Primary database     Nashville - Physical standby database Current status for "DRSolution": SUCCESS

As we can see, our configuration is complete and currently enabled. But having a running configuration wouldn't be any fun unless we have knobs to turn. Let's illustrate how to turn a few of the knobs.

One of the many things we can do with the broker is change the state of either the primary or standby database. We can change the state of the database to be offline or shutdown, stop log transport or log apply, or open in read-only. In the following example, we show how to change the standby of the physical standby to the read-only mode for reporting purposes by editing the broker database object.

DGMGRL> edit database 'Nashville' set state='READ-ONLY'; Succeeded.

To return the physical standby to the recovery mode, we change the state once again.

DGMGRL> EDIT DATABASE 'Nashville' SET STATE='ONLINE'; Succeeded.

The ONLINE state returns the database back to its default state of log apply on.

One common use of the broker is to provide non-DBA support staff a method of performing complex operations without the need to know all of the SQL*Plus commands. One good example is a switchover or failover. Using the broker is a very effective means of providing an easy interface for push-button role transfers to staff that do not necessarily understand all of the underlying concepts and procedures. Let's illustrate how easy a switchover can be performed. You might remember that the switchover process via SQL*Plus we discussed earlier took about eight commands.

DGMGRL> SWITCHOVER TO "Nashville"; Performing switchover NOW. Please wait...

Once the broker completes the switchover process, we are given the following response:

Switchover succeeded. New primary is "Nashville"

Using the Data Guard GUI

Today's community of computer geeks can generally be separated into two groups: those that love the command line and those that long for the GUI. Up to this point we have only serviced the needs of one of these two groups (our prejudice, we must admit). Now the time has come to play fair and delve into the Data Guard GUI.

First, let's cover how to navigate to the Data Guard GUI page within the new OEM interface. This section assumes that you have Grid Control installed and at least your primary database listed as an available target. To reach the Data Guard GUI page, click on the Targets tab, and from the Targets tab click on the Database tab. On the Database tab, you should see your primary database listed. Click on the primary database link to go to the primary database home page. On the primary database home page, click on the Administration tab, where you will find a link to Data Guard under the High Availability section.

If we are using a primary database in which no broker configuration has been created, we are presented with the Add Standby page shown in Figure 7-1. From this page we can create a standby and broker configuration. By clicking on the Add a Standby link we can start the standby creation wizard. If your primary database already has an existing broker configuration-that is, created with the CLI interface- you will not see the page in Figure 7-1.

Figure 7-1: Add a standby

After clicking on the Add a Standby link, we are presented with the page shown in Figure 7-2. This page allows us to create a physical standby or a logical standby, or add an existing physical or logical standby to a Data Guard configuration. It's important to note that if you wish to have a RAC standby database, you must create it manually and add it as an existing standby. Once the RAC standby has been added, the Data Guard GUI can handle all aspects of configuration and management. For our example, we will choose to create a new physical standby.

Figure 7-2: Standby Wizard: standby type

The next page that we are presented with allows us to choose to perform a hot backup of the primary database using RMAN or to use an existing backup that was created during a previous standby creation performed by the Data Guard GUI. For our example, we will choose a live backup of the primary database, as shown in Figure 7-3.

Figure 7-3: Standby Wizard: backup type

When performing the live backup of the primary database, the Data Guard GUI will store the backup files in a working directory prior to sending to the standby host. The page, shown in Figure 7-4, allows us to define the working directory. In addition, we can choose to save the backup for future standby creations. If we choose to save the backup, we will be presented with the backup if we choose the Use an Existing Backup option shown in Figure 7-3. If preferred credentials are not currently defined for the primary database, we are prompted to enter them.

Figure 7-4: Standby Wizard: backup configuration

The next page, shown in Figure 7-5, allows us to set the standby SID name, enter the login information for the standby host, and choose host and ORACLE_HOME for the standby. The SID name can be the same as the primary database, but is often set differently. Choosing a SID that describes its location or purpose is generally preferred. When choosing the standby host and ORACLE_HOME, we are prompted with all hosts and homes that are currently listed as targets within Enterprise Manager and have an operating system that is the same as the primary.

Figure 7-5: Standby Wizard: standby Oracle home

Next, we are given the chance to define if we want the backup of the primary database to be transferred to the standby host via either the FTP or HTTP protocols, or if we want to place the backup on a network share such as NFS. We will transfer the backup via the FTP protocol, as shown in Figure 7-6. We are also asked to define the location in which to place the standby datafiles. A good best practice is to have the directory structures be exactly the same as defined on the primary so as to avoid confusion during role transitions. However, it's acceptable to place the files into a different directory structure. We must also define the directory where the standby Oracle Net configuration files are located. This will allow the Data Guard GUI to add entries to those files.

Figure 7-6: Standby Wizard: file locations

In the final configuration page, shown in Figure 7-7, we are asked to give the standby a unique name within the Data Guard configuration as well as define the Enterprise Manager target name. Also included on this page is the ability to define the directory where archivelogs will be stored on the standby host.

Figure 7-7: Standby Wizard: standby configuration

The last page in the creation process, shown in Figure 7-8, allows us to review our choices. If we would like to modify any values we can simply click the Back button and adjust the value. By selecting the Finish button, we are instructing the Data Guard GUI to proceed with the creation of the standby.

Figure 7-8: Standby Wizard: confirmation

The first step in the standby creation process is the creation of an Enterprise Manager job, shown in Figure 7-9. Several preliminary steps are performed and the Enterprise Manager job is submitted. Once it is submitted, we are returned to the main Data Guard page shown in Figure 7-10. The status of the standby will show as Creation in Progress. You can view the status of the creation process by selecting the Creation in Progress link.

Figure 7-9: Standby Wizard: job creation

Figure 7-10: Data Guard Overview page: creation in progress

Once the creation process has completed, you will be brought to the main Data Guard page, which lists the primary database and all configured standby databases, as shown in Figure 7-11.

Figure 7-11: Data Guard Overview page

From the Data Guard page, we can proceed to modify and monitor the Data Guard environment. For instance, suppose that we want to change the state of the standby from the mounted state running recovery to the open read-only state to allow reporting. To do this, make sure the Standby Radio button is selected and then click on the Edit button. This brings us to the standby database properties page, as shown in Figure 7-12. From this page, we can choose the state in which to place the standby and apply.

Figure 7-12: Standby Database Properties page

To edit the standby role properties of the standby, simply click on the Standby Role Properties link. This presents us with the page shown in Figure 7-13. On this page we can define such items as redo apply delay, log transport mechanism used to ship to the standby, and the use of real-time apply. After modifying any of the values clicking Apply causes them to go into effect.

Figure 7-13: Standby Role Properties page

Once you have your Data Guard configuration up and running, you might want to view specific details about the performance-we discussed several queries that could be used to do this via SQL*Plus. The Data Guard GUI also provides an excellent view of the performance characteristics of your Data Guard configuration. From the main Data Guard page, shown in Figure 7-11, select the Performance Overview link. This brings us to the page shown in Figure 7-14. From this page, we can get a detailed view of all online redo log progress in the configuration at an interval that we define.

Figure 7-14: Performance overview

Finally, The Data Guard GUI provides you with a very fast and complete method to verify your Data Guard configuration. The verify operation performs numerous checks of both the broker configuration and the primary and standby databases. To perform a verification, go to the main Data Guard page shown in Figure 7-11 and select the Verify link under Additional Administration. The verification process will begin immediately, as seen in Figure 7-15. Once it completes, it will alert you to any issues that need to be corrected.

Figure 7-15: Configuration verification

---