Creating a Physical Standby with RMAN Active Duplicate in 126.96.36.199
Other DBAs have written about this topic, but I wanted it to be available on Pythian's blog. When I searched for how this was done, other sites were either not very clear on the steps they did, assumed that you already knew what you are doing, or went through the steps too quickly. If this is your first time building a standby, there is some terminology you need to know before going into any of the steps in creating your physical standby. It will help you to better understand your dataguard environment and what is being done, instead of simply copying a number of steps. These are just the definitions in Oracle's documentation, but they will help you avoid the arduous search.
- LOG_ARCHIVE_DEST_n .- It controls different aspects of how redo transport services transfer redo data from primary database destination to a standby. This parameter has several attributes that are needed to setup your Dataguard environment, I will only mention the critical ones:
- ASYNC .-This is the default, the redo data generated by a transaction need not have been received at a destination which has this attribute before that transaction can commit. or
- SYNC .-The redo data generated by a transaction must have been received by every enabled destination that has this attribute before that transaction can commit.
- AFFIRM and NOAFFIRM .- Control whether a redo transport destination acknowledges received redo data before or after writing it to the standby redo log. The default is NOAFFIRM.
- DB_UNIQUE_NAME .- Specifies a unique name for the database at this destination. You must specify a name; there is no default value.
- VALID_FOR .-Identifies when redo transport services can transmit redo data to destinations based on the following factors:
- redo_log_type .-whether online redo log files, standby redo log files, or both are currently being archived on the database at this destination
- database_role .-whether the database is currently running in the primary or the standby role
- FAL_SERVER .-Specifies the FAL (fetch archive log) server for a standby database. The value is an Oracle Net service name.
- FAL_CLIENT .-Specifies the FAL (fetch archive log) client name that is used by the FAL service, configured through the FAL_SERVER initialization parameter, to refer to the FAL client. The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client (standby database).
- LOG_ARCHIVE_CONFIG .- Enables or disables the sending of redo logs to remote destinations and the receipt of remote redo logs. This parameter has several attributes, the most important for this exercise is below:
- DG_CONFIG .- Specifies a list of up to 30 unique database names (defined with the DB_UNIQUE_NAME initialization parameter) for all of the databases in the Data Guard configuration.
- Primary : testgg1 Server : dlabvm13
- Standby : testgg2 Server : dlabvm14