Using EM12c to set up a Data Guard physical standby database

This post will cover using EM12cR2 to create a Data Guard configuration including one primary database and one physical standby server, making use of the Data Guard broker.  The application software we use does not support logical standby databases so I have not attempted to do so and will not document that here.

Prerequisites

As this post focuses specifically on creating a new Data Guard configuration, I will assume you have an existing functional EM12c environment in place along with two servers to use for Data Guard and an existing database which you wish to protect running on one of those servers.

Both servers should exist as promoted targets within EM12c.  The existing database (along with its listener and ORACLE_HOME) should exist as promoted targets within EM12c. The standby server should have a software-only installation of the same version and patch level of the Oracle Database (Enterprise Edition only) as exists on the primary server. For simplicity I suggest using the same filesystem paths on both servers, although Data Guard does allow rewrite rules if necessary.

Note that Data Guard is a feature included with an Enterprise Edition license but running a physical standby will require a license for the database software on the standby server.  Contact your sales representative for full details.  For the purposes of this post I will assume you are using a copy of the database downloaded from OTN for prototyping purposes.

Configure the database as you wish.  One point I recommend is to make sure that your redo logs are appropriately sized and that you have enough of them, as adding or resizing redo logs after Data Guard is operational requires some special care.

Adding A Physical Standby

Now that your environment is set up with a working EM12c installation and one active database that you wish to protect with a Data Guard physical standby, you can proceed. Start by going to the database home page and select ‘Add Standby Database’ from the drop-down menu under ‘Availability’.

Step 1

On the next page, select ‘Create a new physical standby database’ and click continue.

On the next page you select a method to instantiate the physical standby database.  Select ‘Online Backup’ and ‘Use Recovery Manager (RMAN) to copy database files’, then click Next.

On the next page you specify the degree of parallelism for the RMAN backup, provide operating system credentials for the user owning the Oracle installation on the primary server (oradgd, in my case) and define the locations of the standby redo logs.  The degree of parallelism is up to you and depends on how many CPUs you have and how quickly you need the backup to run.  I specify new named credentials here and save them as preferred database host credentials.  I recommend clicking the ‘Test’ button to validate the supplied credentials.  I do not use Oracle-Managed Files so I have unchecked the box to use them for standby redo log files, which allows me to specify a location for the standby redo logs if I do not like the default.  I left these locations at their default.  After making your entries on this page, click Next.

On the next page you will specify configuration details for the standby database.  All entries on this page relate to the STANDBY server, not the primary.  Enter the hostname of the standby server and the path to the Oracle home installation you will use for the standby database.  Enter credentials for the Oracle home’s software owner, and again I recommend saving them as preferred credentials and clicking the Test button.  The instance name you provide must not already exist on the standby server.  I used the same instance name on the standby as on the primary.  Click Next after entering all required information.

The next page allows you to select the file locations for the standby database and define the listener parameters.  I want to keep things simple with my standby using the same file paths as the primary so I select the radio button labeled “Keep file names and locations the same as the primary database“.  If you wish, you can click the ‘Customize’ button and specify alternate file locations for data files, control files, temp files, directories and external files, but keeping everything identical between the two servers will simplify things greatly. I will also use the default listener name and port.  Click Next once you have made your selections here.

On this page you specify some final parameters for the standby database such as the DB_UNIQUE_NAME, the name EM12c will use for the standby database target, the location for archived redo log files received from the primary, the size of your FRA and the deletion policy for archived redo log files.  For the best monitoring experience, check the ‘Use SYSDBA monitoring credentials’ box.  I also suggest you leave the option checked to use the Data Guard Broker. Click Next once you have made your selections here.

The final page you see here will show a review of the settings you have selected through the process.  You can see here that I am setting up a standby on Oracle Enterprise Linux while my primary runs on SUSE; this is not a problem for Data Guard. Double check everything to make sure it is all correct, and once you are satisfied, click the Finish button.

As soon as you click Finish on the previous screen, EM12c will start setting up your standby database.  You should quickly see a screen like the one below showing that a job has been submitted to create the Data Guard configuration.

If you click on the ‘View Job’ text, you will see the execution log from the job run.

To monitor the job as it proceeds, you can click on the ‘Expand All’ text and then set an auto-refresh interval from the drop-down at the top right. Depending on the size of your database and your server performance, and assuming everything went well, you should soon see that the job has completed successfully.

Validating Data Guard Configuration

Once you see the setup job has succeeded, your Data Guard physical standby is now up and running, actively processing redo from your source database.  You can verify this by returning to the primary database’s home page and clicking the ‘Availability’ menu, which now has additional options such as ‘Data Guard Administration’, ‘Data Guard Performance’ and ‘Verify Data Guard Configuration’.  Click on ‘Data Guard Administration’

The Data Guard administration page shows a summary of your setup.  You can see the host running the primary database, the status of your standby(s) and various metrics like the current and last-applied archived log numbers.  The various links on this page can then be used to change the protection mode, enable/disable fast start failover and so on.  You can also use the ‘Failover’ and ‘Switchover’ buttons to initiate a role transition.  Read the documentation so that you understand the difference and know which to use in which situations.

To help convince yourself that all is working properly, set the auto-refresh interval to 30 seconds and leave this page up.  Open a sqlplus session on your primary database as sysdba and run “alter system switch logfile”.  You should see the log numbers increment once the refresh interval has passed, as shown below.

As a final test, attempt a switchover operation.  This will leave your current primary database running as a standby, while your current standby database takes over the primary role.  Click on the ‘Switchover’ button. Here you are prompted for credentials on the standby database, which is why I suggested saving them as preferred credentials during the setup process.  If you did not do so then, provide appropriate credentials now, then click Continue.

Next you’ll be prompted for credentials for the primary server.  Provide those credentials, if necessary, and then click Continue.

Next you will have one final screen to click through to start the switchover process.  There is a checkbox to choose whether or not you want to swap monitoring settings between the primary and standby databases.  I check the box as this is a good thing, but as the text says you have the option to NOT swap the monitoring settings and instead use your own detailed monitoring templates for each system and apply them after the switchover.  I prefer to keep it simple. Once you are ready to go, click Yes, but be aware this will disconnect any sessions active in your primary database.

You will see a progress screen as the switchover occurs.

Once the switchover completes EM12c will return you to the Data Guard Administration page, where you should see that your primary and standby servers have switched roles.

Conclusion

If you have been following along, you now have a functional Data Guard system with a physical standby and have successfully completed one switchover operation.  You can repeat this process to add another physical standby database on a third server if you wish.  As you look around you’ll also notice a few other changes, such as the additional targets that EM12c added for the standby database, or that the Databases list view has some extra text added that indicates which instance is running as primary and which is running as a standby.  Now it’s time to research your needs for Data Guard and get all the remaining bits configured to best support your users. Good luck!