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.

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’

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!