Skip Headers
Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard
10g Release 2 (10.1.2.3)

Part Number E11078-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Disaster Recovery Special Considerations

This chapter includes the following information about special considerations for OracleAS Disaster Recovery:

4.1 Special Considerations for Some OracleAS Metadata Repository Configurations

This section describes special considerations for multiple OracleAS Metadata Repositories and OracleAS Metadata Repositories created using the OracleAS Metadata Repository Creation Assistant.

4.1.1 Special Considerations for Multiple OracleAS Metadata Repository Configurations

By default, the credentials you specified in the asgctl connect asg command are used whenever one Oracle Application Server Guard server connects to another Oracle Application Server Guard server. However, there may be cases where you want to do either of the following:

If the credentials for any host system are not the same as those used in the asgctl connect command, you must set the Oracle Application Server Guard credentials so that the Oracle Application Server Guard server can connect to each host system in the configuration.

4.1.1.1 Setting asgctl Credentials

To set different credentials for all the host systems belonging to the same topology, enter the following asgctl command at the asgctl prompt. Specify the node name of the host system to which the credentials apply and the ias_admin account name and password for the ias_admin account created during the Oracle Application Server installation, and the key words for topology.

Note:

For Oracle AS 10.1.3.x releases, the user name must be oc4jadmin and the password for the oc4jadmin account created during the Oracle Application Server 10.1.3.x installation.

These settings are good for the current session.

ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd> for topology

When you specify the key words, for topology, you set the credentials for all the host systems that belong to the same topology as the specified system; otherwise, the credentials will apply only for the specified host system.

The set asg credentials command is also useful when you want to use different credentials for a specific server on the topology. In the previous example, the same credentials were set for all nodes on the standby topology, so that these credentials differ from the credentials used in the primary topology. The following command sets the credentials for a specific node, the standbyinfra node, on the standby topology.

ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd>

To summarize, if you set the credentials for a topology, these credentials are inherited for the entire topology. If you set the credentials for an individual host on the topology, the credentials (for this host) override the default credentials set for the topology.

In addition, for topologies that have more than one Infrastructure, such as a collocated Oracle Internet Directory+OracleAS Metadata Repository and a separate Portal OracleAS Metadata Repository, Oracle Application Server Guard requires that you set the credentials for each system on which an Infrastructure resides before performing any important Oracle Application Server Guard operations, such as instantiate, sync, switchover, and failover. See set asg credentials for an example.

4.1.1.2 Specifying the Primary Database

To identify the OracleAS Infrastructure database on the primary topology, enter the following asgctl command at the asgctl prompt. Specify the user name and password for the database account with sysdba privileges to access the OracleAS Infrastructure Database on the primary topology and the TNS service name of the OracleAS Infrastructure database:

ASGCTL> set primary database sys/testpwd@asdb
Checking connection to database asdb
ASGCTL>

The standby site uses the same values as specified for the primary database because the service name and password for both the primary and standby OracleAS Infrastructure databases must be the same.

If a production or standby site has multiple OracleAS Metadata Repository instances installed and you are performing an instantiate, sync, or switchover operation, you must identify all of the OracleAS Metadata Repository instances by performing a set primary database command for each OracleAS Metadata Repository instance before performing either an instantiate, sync, or switchover operation. See set asg credentials for an example.

4.1.1.3 Setting Oracle Application Server Guard Port Numbers

Oracle Application Server Guard uses a default port (port) number of 7890; for example, port=7890. If there are any additional Oracle homes installed on a system, each additional Oracle home must have a unique Oracle Application Server Guard port number, that is usually incremented by the value one, for example, port=7891, and so forth. See Section 2.1.6, "Supported OracleAS Disaster Recovery Configurations" for more information.

4.1.2 Special Considerations for OracleAS Metadata Repository Configurations Created Using OracleAS Metadata Repository Creation Assistant

The following items are special considerations for an OracleAS Metadata Repository configuration created using OracleAS Metadata Repository Creation Assistant. These Metadata Repository databases are installed in Oracle homes with schemas containing user data. For this reason, there are some special considerations regarding OracleAS Disaster Recovery.

  • On the standby site, no Metadata Repository is created by OracleAS Disaster Recovery. The System Administrator must use the OracleAS Metadata Repository Creation Assistant on the standby site and create this Metadata Repository.

  • During a clone topology operation to the standby site no instantiate operation is performed on the Metadata Repository.

  • Warning: Do not perform a clone operation to a standby system containing an existing Oracle home, other than the standalone Oracle Application Server Guard home, because it will get overwritten. Perform a clone operation only to a standby system where no Oracle home is installed other than the standalone Oracle Application Server Guard home.

  • The OracleAS Disaster Recovery solution assumes that user schemas are already configured for Oracle Data Guard.

  • The OracleAS Disaster Recovery solution assumes that when using Oracle Data Guard, that the Metadata Repository is not in managed recovery mode.

  • OracleAS Disaster Recovery will not change the recovery mode of Oracle Data Guard for the Metadata Repository if it is found to be in user-managed recovery mode; instead, Oracle Application Server Guard will issue a warning indicating that the database is in user-managed recovery mode and this feature must be set differently. For more information about user-managed recovery mode, refer to the "Performing User-Managed Database Flashback and Recovery" section of Oracle Database Backup and Recovery User's Guide in the Oracle Database documentation set.

  • Oracle Application Server Guard must be installed in every Oracle Application Server home on every system that is part of your production and standby topology configured for the OracleAS Disaster Recovery solution. The standalone version of Oracle Application Server Guard 10.1.2.3 must also be installed in its own Oracle home on any database host that includes a database that you want to include in your Disaster Recovery topology. After you install the standalone Oracle Application Server Guard kit on the database host, use the asgctl add instance command to add the database instance to your Disaster Recovery topology. The standalone version of Oracle Application Server Guard 10.1.2.3 can be downloaded from Oracle Technology Network at:

    http://www.oracle.com/technology/index.html

    See the OracleAS Disaster Recovery installation information in in Oracle Application Server Installation Guide for more information.

4.2 Special Considerations for OracleAS Disaster Recovery Environments

The following sections describe some additional special considerations for OracleAS Disaster Recovery environments.

4.2.1 Some Special Considerations That Must Be Taken When Setting Up Some OracleAS Disaster Recovery Sites

Some special considerations must be taken when setting up OracleAS Disaster Recovery for sites that include middle-tier CFC configurations.

In CFC configurations, the instance name stored in Oracle Internet Directory is comprised of the original host name on which the production site installation was performed. In the case of an OracleAS Disaster Recovery site having a symmetric topology, the instance on the standby site peer host must be installed identically to the production site or you must use the clone instance or clone topology command to create the instance at the standby site peer host.

4.2.2 Handling dsa.conf or asg.conf Configuration Files for Asymmetric Topologies

The Oracle Application Server Guard operation synchronizes the configuration files of the standby site with those of the production site through a backup operation on the primary site and restores them to the standby site.

Additionally, for asymmetric topologies the dsa.conf configuration file (for 10.1.2.x and 10.1.4.x releases) or asg.conf configuration file (for 10.1.3.x releases) for an Oracle home may contain special settings on the production site that are different from the standby site. For example, the inventory_location parameter setting may be different on the standby site than it is on the primary site. In this case, you should also exclude the dsa.conf or asg.conf configuration file from the backup list of files so it is not restored on the standby site. Otherwise, in this example, the location of the OraInventory will not be correct on the standby site following a switchover or failover operation.

In both these cases, you should modify the OracleAS Recovery Manager backup and restore exclusion file, config_exclude_files.inp, as follows to exclude both of these configuration files from the list of files being backed up, which ensures that neither of these files is then restored to the standby site:

For 10.1.2.x and 10.1.4.x releases:
# Exclude Files
# - Add additional files to this list that you want to be ignored
# - during the configuration file backup/restore
c:\oracle\ias1012\opmn\conf\ons.conf
c:\oracle\ias1012\dsa\dsa.conf

For 10.1.3.x releases:
# Exclude Files
# - Add additional files to this list that you want to be ignored
# - during the configuration file backup/restore
c:\oracle\ias1013\opmn\conf\ons.conf
c:\oracle\ias1013\dsa\asg.conf

The exclusion file is found at:

ORACLE_HOME/backup_restore/config/config_exclude_files.inp

See the backup and recovery part of the Oracle Application Server Administrator's Guide for more information about performing backup and restore operations using OracleAS Recovery Manager.

If the directives set in the dsa.conf file or asg.conf file are necessary at the site that currently functions as the production site, it may be desirable to include the dsa.conf file or asg.conf file for synchronization and add a post switchover or failover step to edit physical site specific directives.

4.2.3 Customized Preference Store Location for Portlets Not Preserved After Switchover Operation

If you change the preference stores of the OmniPortlet and Web Clipping portlets to a location other than the default out-of-box setting (by changing the value in the provider.xml file for OmniPortlet and mds-config.xml file for Web Clipping), you must edit the XML files on the standby site after the switchover operation. You must do this because the switchover operation does not copy over the updated XML files. The location you specify for the preference stores must exist at the standby site.

Table 4-1 shows the location of the XML files for the OmniPortlet and Web Clipping portlets.

Table 4-1 Location of XML Files for OmniPortlet and Web Clipping

Portlet Location of XML File

OmniPortlet

ORACLE_HOME/j2ee/OC4J_WebCenter/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet/provider.xml

Web Clipping

ORACLE_HOME/j2ee/OC4J_WebCenter/applications/portalTools/webClipping/WEB-INF/mds-config.xml


If you do not customize the location of the preference store, then you do not have to edit the XML files after a switchover operation.

4.2.4 Other Special Considerations for OracleAS Disaster Recovery Environments

See Section 5.2, "Information Specific to a Small Set of Oracle Application Server Guard Commands" for information describing some additional special considerations.