Implementing Data Guard - Expert Consolidation in Oracle Database 12c - page 335

Chapter 10

Implementing Data Guard

You were introduced to Data Guard terms and technology in depth in the previous chapter. Now it is time to put
theory into practice. A Data Guard implementation always starts with the duplication of the primary database.
This is easiest done using Recovery Manger, RMAN. The high-level steps are as follows:

1. Check if the primary database is in force-logging mode.

2. Optionally enable Flashback Database on the primary database.

3. Create standby redo logs on the primary database.

4. Create a backup of the primary database if there is not one already.

5. Make the backup of the primary database available on all standby servers.

Create a new init.ora file for each standby database to be created. 6.

7. Duplicate the target database for use as a standby database.

8. Create the Data Guard configuration.

If you have enough network bandwidth, you can clone the database directly over the network without having to
take a backup first. This becomes a true possibility with the wider adoption of 10GB Ethernet networks, except maybe
when long distances are involved.
This chapter will guide you through the process of the standby database creation. There is a slight difference
between using Oracle Managed Files (OMFs) on a file system or Oracle Automatic Storage Management and using the
traditional file system approach. Both approaches will be covered in this chapter.

Naming considerations
Data Guard naming conventions are often the source of considerable controversy. When thinking of using Data Guard
with a database you should consider its use right from the start, especially when using OMFs. The OMF directory
structure follows the following naming convention in ASM:

+diskGroupName/db_unique_name/filetype/fileTypeTag.file#.incarnation

The database unique name is of importance here. If you create your database as PROD with a standby database
unique name of STDBY for example, then the ASM files will be stored in +data/prod/datafile/... and +data/
stdby/datafile/ . Although there is nothing wrong with that, it can cause confusion when the PROD database had to
perform a role change and subsequently is in a standby database role. If your naming standards are flexible enough
you should consider naming the databases you create by location rather than initial role. The confusion about a
database role can be greatly reduced in this case.