C Sync Operations Automated by OracleAS Disaster Recovery

The OracleAS Disaster Recovery solution uses Oracle Data Guard, OracleAS Recovery Manager, Oracle Application Server Guard, and other technologies to automate the synchronization of the OracleAS Disaster Recovery production and standby sites. This chapter describes the operations performed to keep the production and standby sites synchronized.

To keep the OracleAS Disaster Recovery production and standby sites synchronized, you must perform these steps:

Install and configure the OracleAS middle tier and Infrastructure instances, as well as any Oracle databases you want to include in your OracleAS Disaster Recovery topology at the production and standby sites. Refer to Chapter 1, "OracleAS Disaster Recovery Introduction" for more information about installing and configuring Oracle Application Server instances and Oracle databases for OracleAS Disaster Recovery.
Use the asgctl discover topology command at the production site to create the OracleAS Disaster Recovery topology file. Refer to discover topology for more information about the command.
Implement the appropriate backup and recovery strategy for each of the Oracle Application Server instances in your OracleAS Disaster Recovery topology using OracleAS Recovery Manager (previously known as the Backup and Recovery tool), using information provided in the Oracle Application Server Administrator's Guide. OracleAS Recovery Manager is installed by default as part of every Oracle Application Server instance installation.
Make sure that Oracle Data Guard is configured for the Oracle databases in your OracleAS Disaster Recovery topology. Read Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology" for more information about configuring Oracle Data Guard for the Oracle databases in your OracleAS Disaster Recovery topology. The asgctl create standby database command can be used to configure Oracle Data Guard for some databases.
Use the asgctl instantiate topology command to establish the initial relationship between the production site and standby site Application Server instances, mirror the configuration, and synchronize the standby site with the production site. Refer to instantiate topology for more information about the command.
Before the OracleAS Disaster Recovery production site is in use, perform an asgctl sync topology command to create a baseline snapshot of the production site, which can be used later to recover the production site configuration on the standby site, if necessary. Refer to sync topology for more information about the command. The sync topology command automates these operations:
1. Validates the communication path from the production site to the standby site.
2. Ensures that the symmetric topology or asymmetric topology for the production site and standby site that is defined in the OracleAS topology file is maintained.
3. If a policy file is specified with the command, uses the policy file to perform the synchronization specified by the policy file.
4. Confirms that Oracle Data Guard ships OracleAS Infrastructure database archive logs from the production site to the standby site. Refer to Section C.1, "Shipping OracleAS Infrastructure Database Archive Logs to the Standby Site" for more information.
5. Backs up OracleAS Infrastructure and middle tier configuration files at the production site. Refer to Section C.2, "Backing Up OracleAS Infrastructure and Middle Tier Configuration Files at the Production Site" for more information.
6. Restores OracleAS Infrastructure and middle tier configuration files at the standby site. Refer to Section C.3, "Restoring OracleAS Infrastructure and Middle Tier Configuration Files at the Standby Site" for more information.
7. Recovers OracleAS Infrastructure database archive logs at the standby site. Refer to Section C.4, "Restoring OracleAS Infrastructure Database Archive Logs at the Standby Site" for more information.
  
  Note:
  When the sync topology command executes, it synchronizes configuration information between the production and standby sites by synchronizing the backup of OracleAS Infrastructure and middle-tier configuration files with the application of log information on the standby OracleAS Infrastructure database. These operations maintain logical consistency between the configuration of the Oracle Application Server instances and the database.
  For Oracle Application Server, not all the configuration information is in the OracleAS Infrastructure database. The backup of the database files must be kept synchronized with the backup of the middle-tier and OracleAS Infrastructure configuration files. Due to this, log-apply services should not be enabled on the standby database. The log files from the production OracleAS Infrastructure are shipped to the standby OracleAS Infrastructure but are not applied.
Execute the sync topology command whenever there is any administration change in the production site (including changes to the OracleAS Infrastructure database and configuration files on the middle-tier and OracleAS Infrastructure nodes). Also, perform scheduled backup and restore operations (for example, on a daily or twice weekly basis). See the Oracle Application Server Administrator's Guide for more backup and restore procedures.

Note:
Ensure that no configuration changes are being made or will be made to the Oracle Application Server system (underlying configuration files and OracleAS Infrastructure database) when you perform the sync topology command.

C.1 Shipping OracleAS Infrastructure Database Archive Logs to the Standby Site

The sync topology command performs the following operations to initiate the transfer of the archive logs for the OracleAS Infrastructure database to the standby site host:

If log-apply services are not disabled already at the standby site host, the following SQL*Plus command is run on the standby site host to disable the log-apply services:
```
SQL> alter database recover managed standby database cancel;
```
The following command is run to perform a log switch on the production OracleAS Infrastructure database. This ensures that Oracle Data Guard ships the latest log file to the standby OracleAS Infrastructure database
```
SQL> alter system switch logfile;
```
In normal operation of the production site, the production database frequently ships log files to the standby database but they are not applied. At the standby site, the logs are applied to a consistency level. The following SQL statement discovers the System Change Number (SCN) level of the production OracleAS Infrastructure database, encapsulates all the database changes into the latest log, and allows the Oracle Data Guard transport services to transport this log to the OracleAS Infrastructure in the standby site:
```
SQL> select first_change# from v$log where status='CURRENT';
```
The SCN returned by this statement essentially represents the timestamp of the transported log. This SCN is used as the sync point of the sync topology command.
This SCN is used later for the restoration of the production database changes on the standby site, which is described in Section C.4, "Restoring OracleAS Infrastructure Database Archive Logs at the Standby Site."
The previous steps are repeated for each database configured for Oracle Data Guard in the OracleAS Disaster Recovery topology.

C.2 Backing Up OracleAS Infrastructure and Middle Tier Configuration Files at the Production Site

Next, OracleAS Recovery Manager backs up the OracleAS Infrastructure and middle tier configuration files. This step assumes you have installed and configured OracleAS Recovery Manager on each OracleAS installation (middle tier and OracleAS Infrastructure), as it must be customized for each installation. Refer to Oracle Application Server Administrator's Guide for more details about OracleAS Recovery Manager, including installation and configuration instructions.

Note:

After performing the installation and configuration steps for the OracleAS Recovery Manager, which are described in the Oracle Application Server Administrator's Guide, the variables oracle_home, log_path, and config_backup_path in the OracleAS Recovery manager's configuration file, config.inp, have the appropriate values. Also, the following command for the OracleAS Recovery Manager should have been run to complete the configuration:

perl bkp_restore.pl -m configure_nodb

For each middle-tier and OracleAS Infrastructure installation, the following steps are performed (the same steps are used for the OracleAS Infrastructure and middle tier configuration files):

The following command is executed to back up the configuration files from the current installation:
```
perl bkp_restore.pl -v -m backup_config
```
This command creates a directory in the location specified by the config_backup_path variable specified in the config.inp file. The directory name includes the time of the backup. For example: config_bkp_2003-09-10_13-21.
A log of the backup is also generated in the location specified by the log_path variable in the config.inp file. Any errors that occur during the backup process are written to the log files.
The OracleAS Recovery Manager's directory structure and contents from the current host are copied to the equivalent directories on the standby site host, which ensures that the path structure on the standby host is identical to that on the production site host.
The backup directory (as defined by config_backup_path) is copied from the current host to the equivalent directory on the standby site host, which ensures that the path structure on the standby host is identical to that on the production site host.
The previous steps are repeated each Oracle Application Server installation in the production site (OracleAS Infrastructure and middle tier).

C.3 Restoring OracleAS Infrastructure and Middle Tier Configuration Files at the Standby Site

The OracleAS Recovery Manager used to back up the configuration files at the production site restores the backed up files at the standby site.

For each middle-tier and OracleAS Infrastructure installation in the standby site, the following steps are performed (the same steps are used for the OracleAS Infrastructure and middle tier configuration files):

A check is performed to confirm that the OracleAS Recovery Manager directory structure and the backup directory are the same on the production site host and standby site host.
The following OPMN command is used to stop the Oracle Application Server instances and their processes so that no modification of configuration files can occur during the restoration process:

In UNIX:
```
<ORACLE_HOME>/opmn/bin/opmnctl stopall
```
In Windows:
```
<ORACLE_HOME>\opmn\bin\opmnctl stopall
```
OracleAS Recovery Manager executes the following command to determine the valid configuration backup locations:
```
perl bkp_restore.pl -v -m restore_config
```
OracleAS Recovery Manager executes the following command to restore the configuration files:
```
perl bkp_restore.pl -v -m restore_config -t <backup_directory>
```
where <backup_directory> is the name of the directory with the backup files that was copied from the production site. For example, this could be config_bkp_2003-09-10_13-21.
Any errors that occur during the restoration process are written to the log file specified in config.inp.
The previous steps are repeated for each Oracle Application Server installation in the production site (OracleAS Infrastructure and middle tier).

C.4 Restoring OracleAS Infrastructure Database Archive Logs at the Standby Site

During the backup phase described in Section C.1, "Shipping OracleAS Infrastructure Database Archive Logs to the Standby Site," several commands shipped the database log files from the production site to the standby site up to the latest SCN number. A SQL*Plus statement similar to the following statement restores the OracleAS Infrastructure database up to the SCN number at the standby site host by applying the log files to the standby database:

SQL> alter database recover managed standby database from '/private/oracle/oracleas/standby/' standby database until change <SCN>;

Each database in the OracleAS Disaster Recovery topology that is configured with Oracle Data Guard is restored up to the appropriate SCN number using a similar SQL*Plus statement.