A Using Databases in the OracleAS Disaster Recovery Solution

A.1 Installing the Oracle Databases in the Production Site

Install the Oracle databases that will be used at the production site for the Oracle Application Server Disaster Recovery topology that you are setting up.

These databases must exist before you install the Oracle Application Server components that store metadata in database repositories.

If you are setting up the EDG deployment shown in Figure 2-1, for example, you would install the Security Metadata Repository Real Application Clusters (RAC) database on hosts INFRADBHOST1 and INFRADBHOST2 at the production site, and you would also install the Customer RAC database on hosts CUSTDBHOST1 and CUSTDBHOST2 at the production site.

A.2 Creating Standby Databases at the Standby Site

After you install the databases at the production site, the next step is to create a standby database at the standby site for each database included in your Oracle Application Server Disaster Recovery production site.

Create the standby database by following the instructions in the "Creating a Standby Database that Uses OMF or ASM" section of Oracle Data Guard Concepts and Administration in the Oracle Database documentation set.

A.3 Setting Up the Oracle Data Guard Configuration

After creating the production site and standby site database, set up the Oracle Data Guard configuration that Oracle Application Server Disaster Recovery recommends for these databases.

Follow these recommendations to set up the Oracle Data Guard configuration for production site and standby site databases in your Oracle Application Server Disaster Recovery topology:

1. Set up the production site database with the maximum availability data protection mode by issuing the SQL statement in Example A-1:

   Example A-1 Setting Up a Production Site Database in Maximum Availability Data Protection Mode

   ALTER DATABASE SET STANDBY DATABASE DATABASE TO MAXIMIZE AVAILABILITY;
   

   Note:

   Do NOT set up the production site database in maximum protection mode.

2. Set up the standby database with the LGRW SYNC and AFFIRM archive attributes for the LOG_ARCHIVE_DEST_n parameter.

3. Place the standby database at the standby site in managed recovery mode. This puts the standby database in a constant state of media recovery. Placing the standby database in managed recovery mode is not a requirement of maximum availability, but it provides for shorter failover times.

   On the standby database, issue the SQL statement in Example A-2 to place the database in managed recovery mode. Add the optional disconnect from session clause if you want to end the session after the command:

   Example A-2 Placing a Standby Database in Managed Recovery Mode

   ALTER DATABASE RECOVERY MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
   

A.4 Making TNSNAMES.ORA Entries for Databases

Because Oracle Data Guard is used to synchronize production and standby databases, the production database and standby database must be able to reference each other.

Oracle Data Guard uses tnsnames.ora file entries to direct requests to the production and standby databases, so entries for production and standby databases must be made to the tnsnames.ora file. See Oracle Data Guard Concepts and Administration in the Oracle Database documentation set for more information about using tnsnames.ora files with Oracle Data Guard.

A.5 Manually Forcing Database Synchronization with Oracle Data Guard

For Oracle Application Server components that store middle tier configuration data in Oracle database repositories, use Oracle Data Guard to manually force a database synchronization whenever a middle tier synchronization is performed. Use the SQL alter system archive log all statement to switch the logs, which forces the synchronization of the production site and standby site databases.

Example A-3 shows the SQL statement to use to force the synchronization of a production site database and standby site database.

ALTER SYSTEM ARCHIVE LOG ALL;

A.6 Setting Up Database Host Name Aliases

Optionally, you can set up database host name aliases for the databases at your production site and standby site. The alias must be defined in DNS or in the /etc/hosts file on each node running a database instance.

In a Disaster Recovery environment, the site that actively accepts connections is the production site. At the completion of a successful failover or switchover operation, the standby site becomes the new production site.

This section includes an example of defining an alias for database hosts named stajo01 and stajo02. Table A-1 shows the database host names and the connect strings for the databases before the alias is defined

In this example, all database connect strings on the production site take the form "stajo01.us.oracle.com:1521:orcl." After a failover or switchover operation, this connect string must be changed to "stajo02.us.oracle.com:1521:orcl." However, by creating an alias of "proddb1" for the database host name as shown in Table A-2, you can avoid manually changing the connect strings, which enables seamless failovers and switchovers:

In this example, the production site database host name and the standby site database host name are aliased to "proddb1.us.oracle.com" and the connect strings on the production site and the standby site can take the form "proddb1.us.oracle.com:1521:orcl". On failover and switchover operations, the connect string does not need to change, thus enabling a seamless failover and switchover.

The format for specifying aliases in /etc/hosts file entries is:

<IP>    <ALIAS WITH DOMAIN> <ALIAS>    <HOST NAME WITH DOMAIN> <HOST NAME>

In this example, you create a database host name alias of proddb1 for host stajo01 at the production site and for host stajo02 at the standby site. The hosts file entry should specify the fully qualified database host name alias with the <ALIAS WITH DOMAIN> parameter, the short database host name alias with the <ALIAS> parameter, the fully qualified host name with the <HOST NAME WITH DOMAIN> parameter, and the short host name with the <HOST NAME> parameter.

So, in the /etc/hosts files at the production site, make sure the entry for host stajo01 looks like this:

152.68.196.213   proddb1.us.oracle.com proddb1   stajo01.us.oracle.com stajo01

And, in the /etc/hosts files at the standby site, make sure the entry for host stajo02 looks like this:

140.87.25.40   proddb1.us.oracle.com proddb1   stajo02.us.oracle.com stajo02