|Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard
10g Release 2 (10.1.2.3)
Part Number E11078-02
This chapter includes the following information about special considerations for OracleAS Disaster Recovery:
This section describes special considerations for multiple OracleAS Metadata Repositories and OracleAS Metadata Repositories created using the OracleAS Metadata Repository Creation Assistant.
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:
Use different credentials for each system on a given site, see Section 126.96.36.199, "Setting asgctl Credentials."
Use a common set of credentials in the standby topology that are the same as the credentials used in the primary topology, see Section 188.8.131.52, "Specifying the Primary Database."
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.
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.
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.
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.
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.
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:
See the OracleAS Disaster Recovery installation information in in Oracle Application Server Installation Guide for more information.
The following sections describe some additional special considerations for OracleAS Disaster Recovery environments.
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.
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
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:
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.
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|
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.
See Section 5.2, "Information Specific to a Small Set of Oracle Application Server Guard Commands" for information describing some additional special considerations.