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

SQL> alter database add standby logfile
2 '/u01/oradata/CDBFSDCA/srl1.log' size 52428800;

Database altered.

Repeat the above command and create four groups of standby redo logs. Remember that you need n+1 SRL
groups which is one more than online redo logs. If you are multiplexing your online redo logs, which is less and less
common these days, then you only need one member in the standby redo log group. More information about standby
redo logs are in the v$standby_log view.
You should double-check if the primary database has force logging enabled and enable it if needed. The query to
use for this verification is “select force_logging from v$database.”
You can read in the next section how to create a standby database when using ASM. Following that section the
two streams will come together again and you will read more about creating a Data Guard broker configuration.

Configuring Data Guard with Oracle Managed Files
One of the easier configurations to implement with Data Guard is the use of Oracle Managed Files. Oracle Managed
Files or OMF can be implemented as an option when using a file system, or the use is implicit when using Oracle
ASM. With the number of Oracle hardware products and appliances using ASM underneath the covers increasing,
there seems to be a benefit in using ASM throughout.
The creation of the standby database either begins with the backup of the primary database which needs to be
made available on the standby system in exactly the same location as where it was taken on the primary. If you are
using a tape library then this is not a problem, file system based backups however have to use the same directory
structure. The alternative backup-less approach of using the “from active database clause” has already been
demonstrated above and will again be used in this scenario.
Again, you should add the database name to the oratab file.

[oracle@server2 CDB1]$ echo "CDB1DCB:/u01/app/oracle/product/12.1.0.1/dbhome_1:N " \
> >> /etc/oratab

Next copy the password file and the parameter file to the standby host, and rename them to match the instance
name. The standby database's parameter file does not need a lot of change. A careful search-and-replace operation
could again be your starting point, but remember that the db_name parameter must be identical across all standby
databases or you will receive errors. The most common changes for databases include:

• Changing the db_unique_name. but ensure that the db_name remains the same

• Ensuring that the audit_file_dest location is valid

• Changing the dispatchers parameter to match the $ORACLE_SID

• Remove the control_files parameter, it will be overwritten anyway

You also should review the OMF related parameters if your ASM diskgroups or mount points are named
differently from production. As this is a standard deployment no such changes needed to be made. The data files are
standardized to go into the +DATA disk group. The database has its Fast Recovery Area set to +RECO. Here is the final
parameter file for use with the standby database using ASM:

*.audit_file_dest='/u01/app/oracle/admin/CDB1/adump'
*.audit_trail='db'
*.compatible='12.1.0.0.0'
*.db_block_size=8192
*.db_create_file_dest='+DATA'