16 OracleAS Disaster Recovery Site Upgrade Procedure

This chapter describes how to complete a full site Oracle Application Server Disaster Recovery (OracleAS Disaster Recovery) upgrade from OracleAS 10g (9.0.4) to OracleAS 10g (10.1.2.0.2). This procedure assumes that a successful release 9.0.4 to release 10.1.2 upgrade is possible for all the Oracle home types within the topology that define the site and extends these procedures in the OracleAS Disaster Recovery (DR) solution.

This site upgrades an existing supported DR implementation as documented in the Oracle Application Server Disaster Recovery chapter in Oracle Application Server 10g High Availability Guide for OracleAS 10g (9.0.4). This process will not upgrade a non-supported DR environment into an upgraded DR environment. Additionally, this procedure will utilize the standalone OracleAS Guard install within the existing release 9.0.4 Oracle homes and is worded using OracleAS Guard operational steps. If this environment is not possible, the equivalent manual steps can be performed, that is, the OracleAS Guard sync topology command equates to the site synchronization steps documented in the Oracle Application Server Disaster Recovery chapter in Oracle Application Server 10g High Availability Guide for OracleAS 10g (9.0.4).

16.1 Prerequisites

The following are prerequisites for performing a full DR site upgrade from OracleAS 10g (9.0.4) to OracleAS 10g (10.1.2.0.2):

You must have a DR site configured according to the guidelines in Chapter 13, "OracleAS Disaster Recovery".
The OracleAS Backup/Restore utility is installed in all Oracle homes of the both the production and standby sites. The Backup/Restore utility version to be used is the version that supports that release.
The OracleAS 10g (10.1.2.0.2) standalone install of OracleAS Guard, located on Utilities Disk 2, is installed in all OracleAS 10g (9.0.4) Oracle homes. See the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information.

16.2 Disaster Recovery Topology

The systems involved in this DR environment are contained in two sites, site A and site B. The initial roles of each are:

Site A is the production site.
Site B is the standby site.

Due to geographical separation of the sites, it is assumed that the current roles of each of these sites will be the final roles of these same sites at the end of this procedure. However, during the course of the procedure these roles do change. Thus, all references will be to the sites named A and B. Some of the terminology used may be confusing, depending on the role the site is maintaining at a particular point in time.

16.3 High-Level OracleAS Disaster Recovery Upgrade Steps

The following steps describe the OracleAS 10g (9.0.4) to OracleAS 10g (10.1.2.0.2) Disaster Recovery upgrade scenario. These steps refer to Infrastructure systems infra1 and infra2 on site A and site B, respectively.

Install the OracleAS 10g (10.1.2.0.2) standalone install of OracleAS Guard into each Oracle home on the production and standby sites.

If multiple Oracle homes exist on the same system, ensure that different ports are configured for each of the OracleAS Guard servers in this configuration file. The default port number is 7890.
```
<ORACLE_HOME>/dsa/dsa.conf
```

At the standby site [site B], start the OracleAS Guard server:

<ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA

At the production site [site A], connect to OracleAS Guard Infrastructure system infra1 and perform a sync operation.

This operation is used to ensure that the Oracle homes across the topology are logically synchronized.
1. Invoke the asgctl client.
```
On Unix systems
<ORACLE_HOME>/dsa/bin/asgctl.sh

On Windows systems
<ORACLE_HOME>\dsa\bin\asgctl
```
2. Perform a connect operation to site A Infrastructure system infra1.
```
ASGCTL> connect asg infra1 ias_admin/<password>
```
3. Set the primary database to the OracleAS Metadata Repository at site A.
```
ASGCTL> set primary database sys/<password>@<site A's servicename>
```
4. Discover the topology.
```
ASGCTL> discover topology oidpassword=<oidpwd>
```
5. Synchronize the standby site B Infrastructure system infra2 with the production site.
```
ASGCTL> sync topology to infra2
```
6. Ensure there are no changes to the environment through the duration of the upgrade procedure. Note that this does not mean changes to customer data, as this will be in a different database than the Identity Management (IM)/Metadata Repository (MR) data. However, in this model, the IM/MR data will not be able to be synchronized again during the upgrade procedure.
Connect to OracleAS Guard at the standby [site B] Infrastructure and failover.

The purpose of this step is to break the DR environment into two independent sites. This allows site B to be upgraded first. Once site B is upgraded, application level tests can be performed to ensure that the update was completed and that this site is operational. If you use this approach, then site A, production, is not really DR tolerant for the time period of the upgrade. Theoretically, another standby site could be established at this time as site B was upgraded.

The steps to follow to perform the OracleAS Guard failover operation are:
1. Perform a connect operation to site B Infrastructure system infra2.
```
ASGCTL> connect asg infra2 ias_admin/<password>
```
2. Set the new primary database to the OracleAS Metadata Repository at site B.
```
ASGCTL> set new primary database sys/<password>@<site B's servicename>
```
3. Perform the failover operation to this standby site, site B. The failover operation will start all the OPMN managed services across the topology equivalent of an opmnctl startall command.
```
ASGCTL> failover
```
Start the other services for the site at site B.

Any additional services needed for testing must be handled manually, such as applications, database jobs, Enterprise Manager, and so forth.
Perform an OracleAS upgrade to the site B systems [see Oracle Application Server Upgrade and Compatibility Guide for more information].
Test applications or note problems for resolution for the production site. Perform tests until you are satisfied the upgrade has been properly completed.
Redirect site access to site B, if desirable.
1. During the next operation, site A will be upgraded, and Site B can provide some level of service during this upgrade procedure. Theoretically, all access can be given at this time. Once site B is upgraded, requests are serviced there, making this the production role of the DR environment. Once site A is upgraded, the software versions at both sites will be the same and a DR instantiate/sync operation will be possible (as performed in Step 12). If this approach is utilized, any updates made at the original production site [site A] will be lost.
2. If Step 8 a is implemented and site B becomes the production site, then ignore the restrictions in Step 3 f because site A is about to be upgraded.
Perform an OracleAS upgrade to the site A systems [see Oracle Application Server Upgrade and Compatibility Guide for more information].
Test applications or note problems for resolution. Perform tests until you are satisfied the upgrade has been properly completed.

At the end of this step, the two site upgrades are functionally equivalent and have been upgraded to OracleAS Disaster Recovery 10.1.2.0.2 Full site functionality has been enabled at site B and it is time to reestablish the production/standby relationship.
Stop the OracleAS Guard server in all the old OracleAS 9.0.4 Oracle homes, remove the dsa.conf file in the <ORACLE_HOME>/dsa directory on Unix systems or <ORACLE_HOME>\dsa directory on Windows systems, then restart the DSA process as well as the OPMN server on all the systems in the new OracleAS 10.1.2 Oracle homes.

On UNIX systems:
```
<ORACLE_HOME>/opmn/bin/opmnctl stopall
<ORACLE_HOME>/opmn/bin/opmnctl startall
<ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA
```
On Windows systems:
```
<ORACLE_HOME>\opmn\bin\opmnctl stopall
<ORACLE_HOME>\opmn\bin\opmnctl startall
<ORACLE_HOME>\opmn\bin\opmnctl startproc ias-component=DSA
```
Use OracleAS Guard and perform a site instantiation from site B to site A if Step 8 a is utilized.

This step reestablishes the OracleAS Disaster Recovery environment between site B and Site A. In this sequence, site B is the production site, and site A is updated to mirror site B.

Perform the following asgctl steps to complete this operation:
1. Invoke the asgctl client.
```
On Unix systems
<ORACLE_HOME>/dsa/bin/asgctl.sh

On Windows systems
<ORACLE_HOME>\dsa\bin\asgctl
```
2. Perform a connect operation to site B's Infrastructure system infra2.
```
ASGCTL> connect asg infra2 ias_admin/<password>
```
3. Set the primary database to the OracleAS Metadata Repository at site B.
```
ASGCTL> set primary database sys/<password>@<site B's servicename>
```
4. Discover the topology.
```
ASGCTL> discover topology oidpassword=<oidpwd>
```
5. Instantiate the topology to site A's standby Infrastructure system infra1.
```
ASGCTL> instantiate topology to infra1
```
Perform a domain name system (DNS) switchover operation.

You would probably perform this step here to absorb the DNS timeout during the time period of the switchover operation. There will be end user access errors (service unavailable) until DNS, the site services, and the application have all been switched over and are running.
Use OracleAS Guard to perform a switchover operation from site B to site A.

The end goal is to have the same access at the end of upgrade as at the start of the process. Thus the roles have to be switched between the sites. Connect to the Infrastructure for site B, set the primary database, perform a discover topology, then perform a switchover to site A Infrastructure system infra1.
```
ASGCTL> connect asg infra2 ias_admin/<password>
ASGCTL> set primary database sys/<password>@<site B's servicename>
ASGCTL> switchover topology to infra1
```
Note that an alternative to Steps 9 through 14 would be as follows:
1. Take down the production site [site A].
2. Perform an OracleAS upgrade to the site A systems [see Oracle Application Server Upgrade and Compatibility Guide for more information].
3. Perform site A to site B instantiation using OracleAS Guard.
Start or open up services at production site A for the application.

This completes the steps required for the OracleAS Disaster Recovery site upgrade procedure from OracleAS 10g (9.0.4) to OracleAS 10g (10.1.2.0.2).

16.4 Patching an Existing OracleAS Disaster Recovery Environment

For information about how to patch your OracleAS Disaster Recovery environment (patching OracleAS Guard 10.1.2.0.0 with Release 10.1.2.0.2) to take advantage of the features in this latest release of OracleAS Guard, see the platform specific Oracle Application Server Installation Guide and specifically the chapter entitled "Installing in High Availability Environments: OracleAS Disaster Recovery." This chapter contains a section entitled "Patching OracleAS Guard Release 10.1.2.0.0 with Release 10.1.2.0.2" that describes this patching process.