| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
This chapter provides the following following sections about how to configure OracleAS Disaster Recovery with or without using RAC databases in your topology:
Section 3.1, "Configuring OracleAS Disaster Recovery Without Real Application Clusters Databases"
Section 3.2, "Using Oracle Real Application Clusters Database with OracleAS Disaster Recovery"
This section describes how to set up OracleAS Disaster Recovery where neither the primary site nor the standby site uses an Oracle Real Application Clusters database to store the Metadata Repository schemas. This section shows how to use the asgctl create standby database command, which creates the database at the standby site and configures Oracle Data Guard to ship archive logs from the database at the production site to the database at the standby site.
The next section, Section 3.2, "Using Oracle Real Application Clusters Database with OracleAS Disaster Recovery", describes OracleAS Disaster Recovery topologies with Real Application Clusters databases.
This section contains the following subsections:
The following sections include steps that demonstrate how to perform certain tasks:
Section 3.1.2, "Configuration Procedure" shows how to configure an OracleAS Disaster Recovery topology where neither the primary or standby site uses a Real Application Clusters database
Section 3.1.3, "Switchover Procedure" shows how to perform a switchover procedure for this topology
Section 3.1.4, "Switchback Procedure" shows how to perform a switchback procedure for this topology
Section 3.1.5, "Failover Procedure" shows how to perform a failover procedure for this topology
Note the following assumptions for this topology:
Figure 3-1 shows the host and database names used in the Disaster Recovery topology described in this section. Note that neither the production site or the standby site uses a Real Application Clusters database to store the Metadata Repository schemas for the Oracle Application Server instances in the topology. Because one to many Oracle Application Server instances could exist in this topology, the diagram does not depict any Oracle Application Server instances at the production site or standby site but instead states that they access their configuration data in the Metadata Repository schemas in the database at the production site and standby site, respectively.
Figure 3-1 OracleAS Disaster Recovery Topology - non-Real Application Clusters Database at the Production Site and the Standby Site
Table 3-1 shows the host and database names that will be used in the steps in this section.
The vhostdr virtual hostname should be mapped to the system's IP address. You set up this mapping in each system's hosts file. For example:
On the primary site, edit %SystemRoot%\system32\drivers\etc\hosts (Windows) or /etc/hosts (UNIX) to add an entry similar to the following:
ip_address prodnode1.domain.com prodnode1 vhostdr.domain.com vhostdr
On the standby site, edit the hosts file to add an entry similar to the following:
ip_address standbynode1.domain.com standbynode1 vhostdr.domain.com vhostdr
Before proceeding to Section 3.1.2, "Configuration Procedure," do the following:
On host prodnode1 at the primary site, install an OracleAS Infrastructure in its own Oracle home.
On host standbynode1 at the standby site, install the same OracleAS Infrastructure in the equivalent Oracle home directory.
On host prodnode1 at the primary site, create a database in a new Oracle home (not the Oracle AS Infrastructure home). Then use the Oracle Application Server Metadata Repository Creation Assistant to store the Metadata Repository schemas required by the OracleAS Infrastructure in that database. Refer to Oracle Application Server Metadata Repository Creation Assistant User's Guide for more information on using the OracleAS Metadata Repository Creation Assistant to load the Metadata Repository schemas into a database.
On host standbynode1 at the standby site, install only the Oracle Database software in the equivalent database home.
Note:
During the Oracle Database software installation on standbynode1, do not create a database in the home. In Section 3.1.2, "Configuration Procedure," you will use the
create standby database command to create the standby database in the standby site home and to configure Oracle Data Guard so that it will ship archive logs from the primary database at the production site to the standby database at the standby site.
The create standby database command does not work properly if a database exists in the standby site home when the command is executed. Refer to Appendix A, "Database Already Exists Errors During Create Standby" if a database already exists in the home on the standby site peer host.
You must install the standalone version of Oracle Application Server Guard 10.1.2.3 into its own Oracle home on the database host. The standalone version of Oracle Application Server Guard 10.1.2.3 can be found on Oracle Technology Network at:
http://www.oracle.com/technology/index.html
For instructions on how to run the standalone Oracle Application Server Guard installer, see the "Installing in High Availability Environments" chapter in the Oracle Application Server Installation Guide for your platform.
The asgctl set primary database command must be issued for both the primary and standby site within asgctl to define the service name mapping within Oracle Application Server Guard before attempting an asgctl create standby database command
The create standby database command is designed to automate the creation of simple standby databases and to set up the Oracle Data Guard configuration between the primary and standby databases. It does not support some database options, such as the OMF (Oracle Managed Files) or ASM (Automatic Storage Management) storage options. If you plan to use the create standby database command to create a database at the standby site, create the database instance on the primary site without specifying the OMF or ASM storage options.
Databases that use the OMF or ASM storage options can be included in a Disaster Recovery topology, but you cannot use the create standby database command to create a standby database that uses these storage options, and you must use Oracle Data Guard to set up the Oracle Data Guard configuration for the primary and standby databases. See Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology" for more information on configuring Oracle Data Guard for databases that use the OMF or ASM storage options.
The create standby database command must be initiated by ASG clients from the source primary node where the database for the primary site resides.
If you update the AS Recovery Manager's config_misc_files.inp to include other configurations files as part of the backup procedure, special consideration has to be made for corresponding changes at a Disaster Recovery standby site. Changes to this file could be made manually or indirectly through the MDS repository LifeCycle Tool backup option. With each change, files specified in config_misc_files.inp and on a corresponding restore, are restored. However, the config_misc_files.inp is versioned and restored in the form config_misc_files.inp config_misc_files.inp_<backup_time_stamp>. For a Disaster Recovery standby site, the latest version of this file has to be used after a failover or switchover operation. To ensure this configuration change is made, if a timestamped version exists, the latest version of ORACLE_HOME/backup_restore/config/config_misc_files.inp_<backup_time_stamp> in each Oracle home has to be copied to replace the current version of ORACLE_HOME/backup_restore/config/config_misc_files.inp. This must be done after any Oracle Application Server Guard instantiate, failover, or switchover operation.
If you have multiple nodes in the topology on the primary site, then the name of each Oracle Application Server instance must be unique across all the homes on all the nodes in the primary site.
If including multiple databases in a single Disaster Recovery topology, consider the following:
The set primary database command must be invoked individually for each database, before invoking the create standby database command. The create standby database must be run from the system where the primary database resides.
Example:
ASGCTL> set primary database sys/<pass>@orcl1 ASGCTL> create standby database orcl1 on standbynode1 ASGCTL> set primary database sys/<pass>@orcl2 ASGCTL> create standby database orcl2 on standbynode1
The set primary database command must be invoked for each database included in the Disaster Recovery topology for all other Disaster Recovery operations, such as instantiate, switchover, or sync operations. For example:
ASGCTL> set primary database sys/<pass>@orcl1 ASGCTL> set primary database sys/<pass>@orcl2 ASGCTL> sync topology to standbynode1
If databases from 2 different Oracle homes, for example, Oracle 10gR1 db in OHOME1 and Oracle 10gR2 db in OHOME2, on the same system are included in a Disaster Recovery topology, Oracle recommends running the database listener from the Oracle home having the higher database version, for this example, OHOME2.
Perform the following steps to set up a OracleAS Disaster Recovery topology where neither the primary nor the standby site uses a Real Application Clusters database.
Start up the database on prodnode1.
> DBHOME/bin/sqlplus / as sysdba SQL> startup
Create the standby database on the standby node by running the following ASGCTL commands on prodnode1.
Note:
Thecreate standby database command does not work properly if a database exists in the database home on the standby site peer host when the command is executed. If a database already exists in the home on the standby site peer host, follow the instructions in Appendix A, "Database Already Exists Errors During Create Standby" before executing the create standby database command in the following steps.For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg prodnode1 ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg prodnode1 oc4jadmin/<adminpwd> ASGCTL> set trace on all ASGCTL> add instance orcl on vhostdr.oracle.com The output from this dump topology command should list the database instance added in the previous command: ASGCTL> dump topology The output from this verify topology command should indicate that an HA directory exists for the database instance added with the add instance command: ASGCTL> verify topology ASGCTL> set noprompt ASGCTL> set primary database sys/<passwd>@orcl ASGCTL> create standby database orcl on standbynode1 The output from this verify topology command should indicate that an HA directory exists on both the primary site and standby site for the database instance added with the add instance command: ASGCTL> verify topology with standbynode1 ASGCTL> instantiate topology to standbynode1 ASGCTL> sync topology to standbynode1
For scheduled outages of the primary site, you run the ASGCTL switchover topology command to switch over to the standby site. If you have an unscheduled outage, you must perform failover steps as described in Section 3.1.5, "Failover Procedure."
To switchover from the production site to the standby site, perform the following steps:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On prodnode1, invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is standbynode1) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with standbynode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
ASGCTL> set primary database sys/<passwd>@orcl
Switchover the topology to the standby site. If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to standbynode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
When the scheduled outage is over, you switch back from the standby site to the primary site.
Run the following commands to switch back to the primary site:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On standbynode1 (the current primary site), invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is prodnode1, the original primary host) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with prodnode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
ASGCTL> set primary database sys/<passwd>@orcl
Switchover the topology to the standby site (the original primary site). If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to prodnode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
You perform the failover steps to fail over to the standby site when the primary site fails unexpectedly. For scheduled outages, you should perform the steps in Section 3.1.3, "Switchover Procedure" instead.
To fail over to the standby site, run these commands on the standby site and activate it as the new primary site.
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
Connect to the Oracle Application Server Guard server on the standby site. The network name is standbynode1.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases: ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890
Specify that the primary OracleAS Metadata Repository database on the standby site is now identified as the new primary database on this new production site. The keyword new is in bold text in the following example to indicate its importance as a keyword. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set new primary database command.
ASGCTL> set new primary database sys/<passwd>@orcl
Execute the asgctl failover command.
ASGCTL> set trace on all ASGCTL> failover ASGCTL> disconnect
Discover the topology. You must perform this operation to create a new topology file for this production site.
For 10.1.2.x and 10.1.4.x environments, discover the topology as follows:
ASGCTL> discover topology oidpassword=oidpwd
For 10.1.3.x environments, discover the topology as follows:
ASGCTL> discover topology within farm
You can also use the add instance command to add the standalone database instances to the Disaster Recovery topology as follows:
ASGCTL> add instance asdb on vhostdr.oracle.com
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
When you must perform a failover, you should also decide whether to set up a new standby site or not. If you decide to set up a new standby site, then after the failover operation has completed, perform an asgctl create standby database command to create the standby database on the remote host and then perform an asgctl instantiate topology operation.
This section describes how to configure your OracleAS Disaster Recovery topology if you are using a Real Application Clusters database for your OracleAS Metadata Repository. You can use Real Application Clusters database on both your primary and standby sites, or just on the primary site (the standby site uses a non-Real Application Clusters database). The following subsections cover these cases:
Note:
The Disaster Recovery RAC support described in Section 3.2.1, "Configuring OracleAS Disaster Recovery Where Both the Primary and Standby Sites Use Oracle Real Application Clusters Databases" and Section 3.2.2, "Configuring OracleAS Disaster Recovery Where Only the Primary Site Uses Oracle Real Application Clusters Database (Standby Site Uses a Non-Real Application Clusters Database)" is available in Application Server releases 10.1.2.3 and 10.1.3.3.This section describes how to set up OracleAS Disaster Recovery in a topology where both the primary and standby sites use an Oracle Real Application Clusters database to store the OracleAS Metadata Repository schemas. This section shows how to use the asgctl create standby database command, which creates the database at the standby site and configures Oracle Data Guard to ship archive logs from the database at the production site to the database at the standby site.
This section contains the following subsections:
The following sections include steps that demonstrate how to perform certain tasks:
Section 3.2.1.2, "Configuration Procedure" shows how to configure an OracleAS Disaster Recovery topology where both the primary site and standby site uses a Real Application Clusters database
Section 3.2.1.3, "Switchover Procedure" shows how to perform a switchover procedure for this topology
Section 3.2.1.4, "Switchback Procedure (for Switching Back to the Primary Site)" shows how to perform a switchback procedure for this topology
Section 3.2.1.5, "Failover Procedure" shows how to perform a failover procedure for this topology
Note the following assumptions for this topology:
Oracle Real Application Clusters (RAC) software and Oracle Clusterware software has been installed on the primary and standby sites.
Figure 3-2 shows the host and database names used in the Disaster Recovery topology described in this section. Note that the production site and the standby site use a Real Application Clusters database to store the Metadata Repository schemas for the Oracle Application Server instances in the topology. Because one to many Oracle Application Server instances could exist in this topology, the diagram does not depict any Oracle Application Server instances at the production site or standby site but instead states that they access their configuration data in the Metadata Repository schemas in the database at the production site and standby site, respectively.
Figure 3-2 OracleAS Disaster Recovery Topology - Real Application Clusters Database at Production Site and Standby Site
Table 3-2 shows the host and database names that will be used in the steps in the following section. The procedure assumes a two-node Real Application Clusters on each site.
Table 3-2 Host and Database Names on the Primary and Standby Sites
| Primary Site | Standby Site | |
|---|---|---|
|
Physical hostnames |
prodnode1, prodnode2 |
standbynode1, standbynode2 |
|
Virtual hostnames |
vracnode1, vracnode2 |
vracnode1, vracnode2 |
|
Database name |
orcl.oracle.com |
orcl.oracle.com |
|
Database SID |
orcl1 on prodnode1 orcl2 on prodnode2 |
orcl1 on standbynode1 orcl2 on standbynode2 |
The vracnode1 virtual hostname should be mapped to the system's IP address. You set up this mapping in each system's hosts file. For example:
On the primary site, edit %SystemRoot%\system32\drivers\etc\hosts (Windows) or /etc/hosts (UNIX) to add an entry similar to the following:
ip_address prodnode1.domain.com prodnode1 vracnode1.domain.com vracnode1
On the standby site, edit the hosts file to add an entry similar to the following:
ip_address standbynode1.domain.com standbynode1 vracnode1.domain.com vracnode1
Before proceeding to Section 3.2.1.2, "Configuration Procedure" do the following:
On host prodnode1 at the primary site, install an OracleAS Infrastructure in its own Oracle home.
On host standbynode1 at the standby site, install the same OracleAS Infrastructure in the equivalent Oracle home directory.
On host prodnode1 at the primary site, create a database in a new Oracle home (not the Oracle AS Infrastructure home). Then use the Oracle Application Server Metadata Repository Creation Assistant to store the Metadata Repository schemas required by the OracleAS Infrastructure in that database. Refer to Oracle Application Server Metadata Repository Creation Assistant User's Guide for more information on using the OracleAS Metadata Repository Creation Assistant to load the Metadata Repository schemas into a database.
On host standbynode1 at the standby site, install only the Oracle Database software in the equivalent database home.
Note:
During the Oracle Database software installation on standbynode1, do not create a database in the home. In Section 3.2.1.2, "Configuration Procedure" you will use thecreate standby database command to create the standby database in the standby site home and to configure Oracle Data Guard so that it will ship archive logs from the primary database at the production site to the standby database at the standby site.
The create standby database command does not work properly if a database exists in the standby site home when the command is executed. Refer to Appendix A, "Database Already Exists Errors During Create Standby" if a database already exists in the home on the standby site peer host.
You must install the standalone version of Oracle Application Server Guard 10.1.2.3 into its own Oracle home on the database host. The standalone version of Oracle Application Server Guard 10.1.2.3 can be found on Oracle Technology Network at:
http://www.oracle.com/technology/index.html
For instructions on how to run the standalone Oracle Application Server Guard installer, see the "Installing in High Availability Environments" chapter in the Oracle Application Server Installation Guide for your platform.
The create standby database command is designed to automate the creation of simple standby databases and to set up the Oracle Data Guard configuration between the primary and standby databases. It does not support some database options, such as the OMF (Oracle Managed Files) or ASM (Automatic Storage Management) storage options. If you plan to use the create standby database command to create a database at the standby site, create the database instance on the primary site without specifying the OMF or ASM storage options.
Databases that use the OMF or ASM storage options can be included in a Disaster Recovery topology, but you cannot use the create standby database command to create a standby database that uses these storage options, and you must use Oracle Data Guard to set up the Oracle Data Guard configuration for the primary and standby databases. See Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology" for more information on configuring Oracle Data Guard for databases that use the OMF or ASM storage options.
The create standby database command must be initiated by ASG clients from the source primary node where the database for the primary site resides.
The DBName (without domain) and DBSID must be the same when creating the database for a Disaster Recovery setup on primary or standby sites. When you create a new database instance using the DBCA, the SID defaults to the database name. If you enter a name in the SID field other than the database name, and then later add this database to the Disaster Recovery topology, the instance name in the topology added will be empty.
To create a orapwd based password file in the shared location for use by other RAC instances, you must copy over the orapw file to the shared location from the instance on the standby where the database was created after executing the create standby database command. Also after copying the file to the shared location, it should be symlinked to this file from the local disk where it was created.
If a sync topology command in a RAC-RAC Linux environment fails and you receive missing archive logs errors, ping the standby node using tnsping. If you are unable to ping the standby node, stop and restart the listener for that node and retry the tnsping.
If you update the AS Recovery Manager's config_misc_files.inp to include other configurations files as part of the backup procedure, special consideration has to be made for corresponding changes at a Disaster Recovery standby site. Changes to this file could be made manually or indirectly through the MDS repository LifeCycle Tool backup option. With each change, files specified in config_misc_files.inp and on a corresponding restore, are restored. However, the config_misc_files.inp is versioned and restored in the form config_misc_files.inp config_misc_files.inp_<backup_time_stamp>. For a Disaster Recovery standby site, the latest version of this file has to be used after a failover or switchover operation. To ensure this configuration change is made, if a timestamped version exists, the latest version of ORACLE_HOME/backup_restore/config/config_misc_files.inp_<backup_time_stamp> in each Oracle home has to be copied to replace the current version of ORACLE_HOME/backup_restore/config/config_misc_files.inp. This must be done after any Oracle Application Server Guard instantiate, failover, or switchover operation.
If you have multiple nodes in the topology on the primary site, then the name of each Oracle Application Server instance must be unique across all the homes on all the nodes in the primary site.
Perform the following steps to configure OracleAS Disaster Recovery topologies where the primary and standby sites use RAC databases.
Make sure that the database on prodnode1 is running.
Create the standby database on the standby node by running the following ASGCTL commands on prodnode1.
Note:
Thecreate standby database command does not work properly if a database exists in the database home on the standby site peer host when the command is executed. If a database already exists in the home on the standby site peer host, follow the instructions in Appendix A, "Database Already Exists Errors During Create Standby" before executing the create standby database command in the following steps.Here are some notes on the commands in the following section:
On UNIX, the add instance command uses orcl (the database name) to locate the oratab entry.
On Windows, it uses orcl1 (the database SID) to locate the registry entry.
The set primary database and create standby database commands use orcl (the database name) on UNIX, but on Windows they use orcl1 (the database SID).
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg prodnode1 ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg prodnode1 oc4jadmin/<adminpwd> ASGCTL> set trace on all UNIX only: ASGCTL> add instance orcl on vracnode1.oracle.com Windows only: ASGCTL> add instance orcl1 on vracnode1.oracle.com The output from this dump topology command should list the database instance added in the previous command: ASGCTL> dump topology The output from this verify topology command should indicate that an HA directory exists for the database instance added with the add instance command: ASGCTL> verify topology ASGCTL> set noprompt UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1 UNIX only: ASGCTL> create standby database orcl on standbynode1 Windows only: ASGCTL> create standby database orcl1 on standbynode1 The output from this verify topology command should indicate that an HA directory exists on both the primary site and standby site for the database instance added with the add instance command: ASGCTL> verify topology with standbynode1 ASGCTL> instantiate topology to standbynode1
On standbynode1, modify parameters in the initorcl1.ora file.
On standbynode1, make a backup copy of the file DBHOME/dbs/initorcl1.ora (UNIX) or DBHOME\database\initorcl1.ora (Windows). You will be editing the file in the next step.
Verify that these parameters in DBHOME/dbs/initorcl1.ora (UNIX) or DBHOME\database\initorcl1.ora (Windows) are set to valid values:
*.cluster_database_instances=2 *.cluster_database=TRUE *.remote_listener='LISTENERS_ORCL'
Copy initorcl1.ora from standbynode1 to the corresponding directory on standbynode2 (DBHOME/dbs on UNIX, DBHOME\database on Windows).
On standbynode2, rename the file to initorcl2.ora.
On standbynode2, update the initorcl2.ora file to replace any instance-specific parameters. For example, you would change these lines:
*.service_names=orcl1 *.instance_name=orcl1
to:
*.service_names=orcl2 *.instance_name=orcl2
Only on UNIX platforms, create an admin directory under the default ADMIN directory of the database ($ADMINDIR/<dbname>/admin) on standbynode2. If the directory already exists, please skip this step:
mkdir $ohome/admin/<dbname>/admin
Propagate orcl_remote1 or orcl1_remote1 entries from standbynode1 to other RAC nodes on the standby site.
Copy the orcl_remote1 (UNIX) or orcl1_remote1 (Windows) entries in tnsnames.ora on standbynode1 to all the other RAC nodes on the standby site.
On UNIX, the entry uses the database name (orcl), but on Windows it uses the database SID (orcl1). A "_remote<n>" is appended to the name of the entry, where <n> is a number.
In some cases, the <n> number will advance, and the _remote<n> entry specified in the SERVICE attribute of the LOG_ARCHIVE_DEST_<n> parameter must be propagated as well.
On standbynode2, restart the listener using Oracle Clusterware:
> CRSHOME/bin/crs_stop ora.standbynode2.LISTENER_STANDBYNODE2.lsnr > CRSHOME/bin/crs_start ora.standbynode2.LISTENER_STANDBYNODE2.lsnr
Make sure that the standby database mentioned in the remote entry is pingable using TNS.
UNIX only: > tnsping orcl_remote1 Windows only: > tnsping orcl1_remote1
On standbynode2, start up the database, create an spfile, and shut down the database.
SQL> startup; UNIX only: SQL> create spfile='<ORADATASHAREDLOCATION>/orcl/spfileorcl.ora' from pfile='<DBHOME>/dbs/initORCL2.ora'; Windows only: SQL> create spfile='<ORADATASHAREDLOCATION>\orcl\spfileorcl.ora' from pfile='<DBHOME>/database/initORCL2.ora'; SQL> shutdown immediate;
Backup initORCL1.ora and initORCL2.ora on standbynode1 and standbynode2.
On standbynode1, modify initORCL1.ora to include only the following line:
cat initORCL1.ora SPFILE='<ORADATASHAREDLOCATION>/ORCL/spfileorcl.ora'
On standbynode2, modify initORCL2.ora to include only the following line:
cat initORCL2.ora SPFILE='<ORADATASHAREDLOCATION>/ORCL/spfileorcl.ora'
On prodnode1, run the asgctl sync topology command.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg oc4jadmin/<adminpwd> UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1 ASGCTL> sync topology to standbynode1
This section describes how to run the ASGCTL switchover topology command to switch from the primary site to the standby site to prepare for a scheduled outage of the primary site.
After the scheduled outage is over, you can switch back to the primary site. See Section 3.2.1.4, "Switchback Procedure (for Switching Back to the Primary Site)" for details.
For unscheduled outages, you should perform the steps in Section 3.2.1.5, "Failover Procedure" instead.
Procedure for switching over to the standby site for scheduled outages:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On prodnode1, invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is standbynode1) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with standbynode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
UNIX only: ASGCTL> set primary database sys/<paswd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1
Switchover the topology to the standby site. If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to standbynode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
If the database uses temp files (for example, temp01.dbf), delete these files from <ORADATASHAREDLOCATION> on standbynode1.
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
When the scheduled outage of the primary site is over, perform these steps to switch back to the primary site.
Run the following commands to switch back to the primary site:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On standbynode1 (the current primary site), invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is prodnode1, the original primary host) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with prodnode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1
Switchover the topology to the standby site (the original primary site). If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to prodnode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
This section describes the steps for failing over to the standby site. Use these steps for unscheduled outages of the primary site. For scheduled outages, see the steps in Section 3.2.1.3, "Switchover Procedure".
To fail over to the standby site, run these commands on the standby site and activate it as the new primary site.
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
Connect to the Oracle Application Server Guard server on the standby site. The network name is standbynode1.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd>
Specify that the primary OracleAS Metadata Repository database on the standby site is now identified as the new primary database on this new production site. The keyword new is in bold text in the following example to indicate its importance as a keyword. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set new primary database command.
UNIX only: ASGCTL> set new primary database sys/<passwd>@orcl Windows only: ASGCTL> set new primary database sys/<passwd>@orcl1
Execute the asgctl failover command.
ASGCTL> set trace on all ASGCTL> failover ASGCTL> disconnect
Discover the topology. You must perform this operation to create a new topology file for this production site.
For 10.1.2.x and 10.1.4.x environments, discover the topology as follows:
ASGCTL> discover topology oidpassword=oidpwd
For 10.1.3.x environments, discover the topology as follows:
ASGCTL> discover topology within farm
You can also use the add instance command to add the standalone database instances to the Disaster Recovery topology as follows:
ASGCTL> add instance asdb on vracnode1.oracle.com
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
When you must perform a failover, you should also decide whether to set up a new standby site or not. If you decide to set up a new standby site, then after the failover operation has completed, perform an asgctl create standby database command to create the standby database on the remote host and then perform an asgctl instantiate topology operation.
This section describes how to set up OracleAS Disaster Recovery in a topology where the primary site uses an Oracle Real Application Clusters database to store the OracleAS Metadata Repository schemas, and the standby site uses a non-Real Application Clusters database to store the OracleAS Metadata Repository schemas. This section shows how to use the asgctl create standby database command, which creates the database at the standby site and configures Oracle Data Guard to ship archive logs from the database at the production site to the database at the standby site.
This section contains the following subsections:
The following sections include steps that demonstrate how to perform certain tasks:
Section 3.2.2.2, "Configuration Procedure" shows how to configure an OracleAS Disaster Recovery topology where the primary site uses an Oracle Real Application Clusters database and the standby site uses a non-Real Application Clusters database
Section 3.2.2.3, "Switchover Procedure" shows how to perform a switchover procedure for this topology
Section 3.2.2.4, "Switchback Procedure" shows how to perform a switchback procedure for this topology
Section 3.2.2.5, "Failover Procedure" shows how to perform a failover procedure for this topology
Note the following assumptions for this topology:
Oracle Real Application Clusters (RAC) software and Oracle Clusterware software has been installed on the primary site.
Figure 3-3 shows the host and database names used in the Disaster Recovery topology described in this section. Note that the production site uses a RealApplication Clusters database and the standby site use a non-Real Application Clusters database to store the Metadata Repository schemas for the Oracle Application Server instances in the topology. Because one to many Oracle Application Server instances could exist in this topology, the diagram does not depict any Oracle Application Server instances at the production site or standby site but instead states that they access their configuration data in the Metadata Repository schemas in the database at the production site and standby site, respectively.
Figure 3-3 OracleAS Disaster Recovery Topology - Real Application Clusters Database at Production Site and non-Real Application Clusters Database at Standby Site
Table 3-3 shows the host and database names that will be used in the steps in the following section. The procedure assumes a two-node Real Application Clusters on the primary site.
Table 3-3 Host and Database Names on the Primary and Standby Sites
| Primary Site | Standby Site | |
|---|---|---|
|
Physical hostnames |
prodnode1, prodnode2 |
standbynode1 |
|
Virtual hostnames |
vracnode1, vracnode2 |
vracnode1 |
|
Database name |
orcl.oracle.com |
orcl.oracle.com |
|
Database SID |
orcl1 on prodnode1 orcl2 on prodnode2 |
orcl1 on standbynode1 |
The vracnode1 virtual hostname should be mapped to the system's IP address. You set up this mapping in each system's hosts file. For example:
On the primary site, edit %SystemRoot%\system32\drivers\etc\hosts (Windows) or /etc/hosts (UNIX) to add an entry similar to the following:
ip_address prodnode1.domain.com prodnode1 vracnode1.domain.com vracnode1
On the standby site, edit the hosts file to add an entry similar to the following:
ip_address standbynode1.domain.com standbynode1 vracnode1.domain.com vracnode1
Before proceeding to Section 3.2.2.2, "Configuration Procedure," do the following:
On host prodnode1 at the primary site, install an OracleAS Infrastructure in its own Oracle home.
On host standbynode1 at the standby site, install the same OracleAS Infrastructure in the equivalent Oracle home directory.
On host prodnode1 at the primary site, create a database in a new Oracle home (not the Oracle AS Infrastructure home). Then use the Oracle Application Server Metadata Repository Creation Assistant to store the Metadata Repository schemas required by the OracleAS Infrastructure in that database. Refer to Oracle Application Server Metadata Repository Creation Assistant User's Guide for more information on using the OracleAS Metadata Repository Creation Assistant to load the Metadata Repository schemas into a database.
On host standbynode1 at the standby site, install only the Oracle Database software in the equivalent database home.
Note:
During the Oracle Database software installation on standbynode1, do not create a database in the home. In Section 3.2.2.2, "Configuration Procedure," you will use thecreate standby database command to create the standby database in the standby site home and to configure Oracle Data Guard so that it will ship archive logs from the primary database at the production site to the standby database at the standby site.
The create standby database command does not work properly if a database exists in the standby site home when the command is executed. Refer to Appendix A, "Database Already Exists Errors During Create Standby" if a database already exists in the home on the standby site peer host.
You must install the standalone version of Oracle Application Server Guard 10.1.2.3 into its own Oracle home on the database host. The standalone version of Oracle Application Server Guard 10.1.2.3 can be found on Oracle Technology Network at:
http://www.oracle.com/technology/index.html
For instructions on how to run the standalone Oracle Application Server Guard installer, see the "Installing in High Availability Environments" chapter in the Oracle Application Server Installation Guide for your platform.
The create standby database command is designed to automate the creation of simple standby databases and to set up the Oracle Data Guard configuration between the primary and standby databases. It does not support some database options, such as the OMF (Oracle Managed Files) or ASM (Automatic Storage Management) storage options. If you plan to use the create standby database command to create a database at the standby site, create the database instance on the primary site without specifying the OMF or ASM storage options.
Databases that use the OMF or ASM storage options can be included in a Disaster Recovery topology, but you cannot use the create standby database command to create a standby database that uses these storage options, and you must use Oracle Data Guard to set up the Oracle Data Guard configuration for the primary and standby databases. See Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology" for more information on configuring Oracle Data Guard for databases that use the OMF or ASM storage options.
The DBName (without domain) and DBSID must be the same when creating the database for a Disaster Recovery setup on primary or standby sites. When you create a new database instance using the DBCA, the SID defaults to the database name. If you enter a name in the SID field other than the database name, and then later add this database to the Disaster Recovery topology, the instance name in the topology added will be empty.
If a sync topology command in a RAC-Non RAC Linux environment fails and you receive missing archive logs errors, ping the standby node using tnsping. If you are unable to ping the standby node, stop and restart the listener for that node and retry the tnsping.
If you update the AS Recovery Manager's config_misc_files.inp to include other configuration files as part of the backup procedure, special consideration has to be made for corresponding changes at a Disaster Recovery standby site. Changes to this file could be made manually or indirectly through the MDS repository LifeCycle Tool backup option. With each change, files specified in config_misc_files.inp and on a corresponding restore, are restored. However, the config_misc_files.inp is versioned and restored in the form config_misc_files.inp config_misc_files.inp_<backup_time_stamp>. For a Disaster Recovery standby site, the latest version of this file has to be used after a failover or switchover operation. To ensure this configuration change is made, if a timestamped version exists, the latest version of ORACLE_HOME/backup_restore/config/config_misc_files.inp_<backup_time_stamp> in each Oracle home has to be copied to replace the current version of ORACLE_HOME/backup_restore/config/config_misc_files.inp. This must be done after any Oracle Application Server Guard instantiate, failover, or switchover operation.
If you have multiple nodes in the topology on the primary site, then the name of each Oracle Application Server instance must be unique across all the homes on all the nodes in the primary site.
Perform the following steps to configure your OracleAS Disaster Recovery topology where the primary site uses a RAC database, but the standby site uses a non-RAC database.
Make sure that the database on prodnode1 is running.
Create the standby database on the standby node by running the following ASGCTL commands on prodnode1.
Note:
Thecreate standby database command does not work properly if a database exists in the database home on the standby site peer host when the command is executed. If a database already exists in the home on the standby site peer host, follow the instructions in Appendix A, "Database Already Exists Errors During Create Standby" before executing the create standby database command in the following steps.Here are some notes on the commands in the following section:
On UNIX, the add instance command uses orcl (the database name) to locate the oratab entry.
On Windows, it uses orcl1 (the database SID) to locate the registry entry.
The set primary database and create standby database commands use orcl (the database name) on UNIX, but on Windows they use orcl1 (the database SID).
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg prodnode1 ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg prodnode1 oc4jadmin/<adminpwd> ASGCTL> set trace on all UNIX only: ASGCTL> add instance orcl on vracnode1.oracle.com Windows only: ASGCTL> add instance orcl1 on vracnode1.oracle.com The output from this dump topology command should list the database instance added in the previous command: ASGCTL> dump topology The output from this verify topology command should indicate that an HA directory exists for the database instance added with the add instance command: ASGCTL> verify topology ASGCTL> set noprompt UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1 UNIX only: ASGCTL> create standby database orcl on standbynode1 Windows only: ASGCTL> create standby database orcl1 on standbynode1 The output from this verify topology command should indicate that an HA directory exists on both the primary site and standby site for the database instance added with the add instance command: ASGCTL> verify topology with standbynode1 ASGCTL> instantiate topology to standbynode1
Propagate orcl_remote1 or orcl1_remote1 entries from prodnode1 to other nodes on the primary site.
Copy the orcl_remote1 (UNIX) or orcl1_remote1 (Windows) entries in tnsnames.ora on prodnode1 to all the other RAC nodes on the primary site.
On UNIX, the entry uses the database name (orcl), but on Windows it uses the database SID (orcl1). A "_remote<n>" is appended to the name of the entry, where <n> is a number.
In some cases, the <n> number will advance, and the _remote<n> entry specified in the SERVICE attribute of the LOG_ARCHIVE_DEST_<n> parameter must be propagated as well.
On prodnode2, restart the listener using Oracle Clusterware:
> CRSHOME/bin/crs_stop ora.prodnode2.LISTENER_PRODNODE2.lsnr > CRSHOME/bin/crs_start ora.prodnode2.LISTENER_PRODNODE2.lsnr
Make sure that the standby database mentioned in the remote entry is pingable using TNS.
UNIX only: > tnsping orcl_remote1 Windows only: > tnsping orcl1_remote1
On prodnode1, run the ASGCTL sync topology command.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg oc4jadmin/<adminpwd> UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1 ASGCTL> sync topology to standbynode1
This section describes how to run the ASGCTL switchover topology command to switch from the primary site to the standby site to prepare for a scheduled outage of the primary site.
After the scheduled outage is over, you can switch back to the primary site. See Section 3.2.2.4, "Switchback Procedure" for details.
For unscheduled outages, you should perform the steps in Section 3.2.2.5, "Failover Procedure" instead.
Procedure for switching over to the standby site for scheduled outages:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On prodnode1, invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg ias_admin/<adminpwd> Successfully connected to prodnode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg oc4jadmin/<adminpwd> Successfully connected to prodnode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is standbynode1) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with standbynode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
UNIX only: ASGCTL> set primary database sys/<paswd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1
Switchover the topology to the standby site. If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to standbynode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
This section describes the steps for switching back to the primary site when the scheduled outage is over.
Run the following commands to switch back to the primary site:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
On standbynode1 (the current primary site), invoke the Oracle Application Server Guard client command-line utility asgctl (asgctl.sh is located in <ORACLE_HOME>/dsa/bin on UNIX systems and asgctl.bat is located in <ORACLE_HOME>\dsa\bin on Windows systems) and then connect to the Oracle Application Server Guard server:
For 10.1.2.x and 10.1.4.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on UNIX: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.2.x and 10.1.4.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> Successfully connected to standbynode1:7890 For 10.1.3.x releases on Windows: > asgctl.bat Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd> Successfully connected to standbynode1:7890
Use the verify topology command to confirm that the production topology is running and the configuration is valid:
ASGCTL> verify topology
Use the verify topology and specify the standby Infrastructure host (the standby Infrastructure host's network hostname is prodnode1, the original primary host) to confirm that the standby topology is consistent with the production site and meets Disaster Recovery requirements:
ASGCTL> verify topology with prodnode1
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information:
UNIX only: ASGCTL> set primary database sys/<passwd>@orcl Windows only: ASGCTL> set primary database sys/<passwd>@orcl1
Switchover the topology to the standby site (the original primary site). If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file:
ASGCTL> switchover topology to prodnode1
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old production site Oracle Application Server Guard server:
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
This section describes the steps for failing over to the standby site. Use these steps for unscheduled outages of the primary site. For scheduled outages, see the steps in Section 3.2.2.3, "Switchover Procedure."
To fail over to the standby site, run these commands on the standby site and activate it as the new primary site.
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
Connect to the Oracle Application Server Guard server on the standby site. The network name is standbynode1.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg standbynode1 ias_admin/<adminpwd> For 10.1.3.x releases: ASGCTL> connect asg standbynode1 oc4jadmin/<adminpwd>
Specify that the primary OracleAS Metadata Repository database on the standby site is now identified as the new primary database on this new production site. The keyword new is in bold text in the following example to indicate its importance as a keyword. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set new primary database command.
UNIX only: ASGCTL> set new primary database sys/<passwd>@orcl Windows only: ASGCTL> set new primary database sys/<passwd>@orcl1
Execute the asgctl failover command.
ASGCTL> set trace on all ASGCTL> failover ASGCTL> disconnect
Discover the topology. You must perform this operation to create a new topology file for this production site.
For 10.1.2.x and 10.1.4.x environments, discover the topology as follows:
ASGCTL> discover topology oidpassword=oidpwd
For 10.1.3.x environments, discover the topology as follows:
ASGCTL> discover topology within farm
You can also use the add instance command to add the standalone database instances to the Disaster Recovery topology as follows:
ASGCTL> add instance asdb on vracnode1.oracle.com
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations."
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
When you must perform a failover, you should also decide whether to set up a new standby site or not. If you decide to set up a new standby sitie, then after the failover operation has completed, perform an asgctl create standby database command to create the standby database on the remote host and then perform an asgctl instantiate topology operation.
