|Oracle® Application Server Release Notes
10g (10.1.4.0.1) for Microsoft Windows (64-Bit) on Intel Itanium
Part Number B32107-06
This chapter describes issues related to highly available topologies using the OracleAS Disaster Recovery solution. This chapter contains the following issues:
This section describes general issues and workarounds. It includes the following topic:
Oracle recommends that you upgrade your systems to release 10.1.2.2.1 of OracleAS Guard using the standalone OracleAS Guard kit 10.1.2.2.1 installation kit, which is available on Oracle Technology Network at:
At the current time, the semantics of an asgctl clone topology operation will not clone databases that are outside of the OracleAS home, thus only the default database installed into the OracleAS home by some infrastructure installation types will be cloned. The asgctl create standby database command should be used by users not familiar with Oracle Data Guard.
OracleAS Guard version shipped with this release is 10.1.2.1.1. This version of OracleAS Guard cannot be used with Oracle RAC Databases. For all other purposes, this OracleAS Guard version is completely supported by Oracle.
To use OracleAS Guard with an Oracle RAC database, it is recommended to use Release 10.1.2.2 stand alone version of OracleAS Guard with this release. OracleAS Guard 10.1.2.2 version (with instructions) is available for download from Oracle OTN as an OracleAS Guard stand alone install, or please contact Oracle Support for further instructions.
When OracleAS Guard could not find the user specified identifier, an inappropriate error message was returned. If the user had entered the database name rather that the Oracle instance SID, there was no indication that this was the problem.
Now if OracleAS Guard is unable to locate the oratab entry (on Unix) or the system registry service (on Windows) for the user specified database identifier, the following ASG_SYSTEM-100 message now precedes the existing ASG_DUF-3554 message and both messages will be displayed to the console:
On Unix systems: ASG_SYSTEM-100: An Oracle database is identified by its database unique name (db_name) ASG_DUF-3554: The Oracle home that contains SID <user specified identifier> cannot be found On Windows systems: ASG_SYSTEM-100: An Oracle database is identified by its system identifier (SID) ASG_DUF-3554: The Oracle home that contains SID <user specified identifier> cannot be found
This section describes configuration issues and their workarounds. It includes the following topics:
The same TEMP directory structure that exists on a primary site must be set up on the standby site, otherwise DCM will not work properly. An OracleAS Guard verify operation does not detect this problem.
The work around for this problem is for the High Availability Administrator to maintain the same TEMP directories on both the primary and standby sites. When creating environment variables for the standby site, ensure that each standby peer's environment is a replica of the production home. An area that is commonly forgotten or overlooked is the TEMP directory.
The asgctl shutdown topology command only handles non-database instances. Thus, in a repCA environment when OracleAS Guard detects an instance and determines it to be a repCa type database, its instance is ignored in a shutdown topology operation. Any repCA type database is considered to be managed outside of OracleAS Guard.
The SIDs must be the same for database peers at a primary site and standby site(s) in a Disaster Recovery topology.
Use all uppercase characters for database initialization parameters.
In the following example, the database initialization parameter, service, that is used in the archive log destination parameter is in all uppercase characters (SERVICE):
log_archive_dest_2="SERVICE=SIDM valid_for=(online_logfiles,primary_role) db_unique_name=SIDM"
But in the following example, the database initialization parameter, service, that is used in the archive log destination parameter is in lowercase characters (service):
log_archive_dest_2="service=SIDM valid_for=(online_logfiles,primary_role) db_unique_name="SIDM"
When the database initialization parameter is not in all uppercase characters, error messages similar to the following can occur during an
instantiate topology or
sync topology operation:
stajo05: -->ASG_DUF-4950: An error occurred on host "stajo05" with IP "184.108.40.206" and port "7890" stajo05: -->ASG_SYSTEM-100: String index out of range: -9 stajo05: -->ASG_DUF-3760: Failed to query archive log destination information. stajo05: -->ASG_IAS-15753: Error preparing to instantiate the topology on host "stajo05" stajo05: -->ASG_DUF-3027: Error while executing Instantiating each instance in the topology to standby topology at step - prepare step.
Use the same port for ASG on the primary site and standby site(s) to avoid error messages such as the following during a
clone instance operation:
3-May 15:45:43 >>clone instance prodsso1 to stbyinfra1 3-May 15:45:43 stamx11: -->ASG_DUF-4950: An error occurred on host "stamx11" with IP "220.127.116.11" and port "7890" stamx11: -->ASG_DUF-3601: Error connecting to server host 18.104.22.168 on port 7890 stamx11: -->ASG_DUF-3512: Error creating remote worker on node 22.214.171.124:7890.
The dsa.conf file contains ASG configuration information, and it is configured into the Application Server instance's backup/restore IP configuration. The dsa.conf file configuration is handled symmetrically between Application Server instances. Due to this, the dsa.conf file from a production site's instance will be synchronized to the corresponding standby site's instance.
The port numbers between the production and standby instance pairings should match for ASG.
As a best practice, use fully qualified path names with the
add instance command.
clone topology and
clone instance commands are not supported by DR configurations if there are a different number of Oracle Homes at the primary and standby hosts.
As part of the cloning operation, the Oracle Inventory for each host is cloned. Therefore, the assumption is that the Oracle Home configuration is symmetrical for any host that is being cloned.
For a full description of supported Disaster Recovery asymmetric topologies, refer to Section 126.96.36.199 of the Application Server High Availability Guide for release 10.1.3.2.0.
On Windows systems, perform the following workarounds before performing cloning operations in Disaster Recovery configurations:
Install version 5.0.2134.1 or higher of sc.exe (the services kit) under the C:\windows\system32 directory before performing cloning operations in Disaster Recovery configurations.
If you do not take this step prior to performing a cloning operation on Windows, you may see errors similar to these during an ASG cloning operation:
stajz09: -->ASG_DUF-4040: Error executing the external program or script. The error code is "255" stajz09: -->ASG_IAS-15689: Error running the backup script stajz09: -->ASG_IAS-15685: Failed to backup configuration data for instance "IM.asinfra.us.oracle.com" stajz09: -->ASG_DUF-3027: Error while executing Clone Instance at step - backup step. stajz09: -->ASG_DUF-3027: Error while executing Clone Topology at step - clone home step.
For the dcm-daemon component in the %ORACLE_HOME%\opmn\conf\opmn.xml file, increase the start timeout parameter's retry interval to 5 seconds. The following example shows the section of the opmn.xml file for the dcm-daemon component with the start timeout parameter's retry interval set to 5:
<ias-component id="dcm-daemon" status="enabled" id-matching="true"> <process-type id="dcm-daemon" module-id="DCMDaemon"> <start timeout="600" retry="5"/> <stop timeout="120"/> <process-set id="dcm" numprocs="1">
If you do not take this second step prior to performing a cloning operation on Windows, you may see errors similar to these during an ASG cloning operation:
stajz09: -->ASG_SYSTEM-100: Command "C:\work\im/opmn/bin/opmnctl.exe shutdown" failed, check log file C:\work\im\dsa\bkup\log/2007-07-17_01-41-51_loha.log for detail. stajz09: -->ASG_SYSTEM-100: Failure : prepare failed stajz09: -->ASG_SYSTEM-100: stajz09: -->ASG_SYSTEM-100: OPMN managed processes could not be stopped. stajz09: -->ASG_SYSTEM-100: Status code: stajz09: -->ASG_SYSTEM-100: opmnctl shutdown failed.
If the 10.1.2.2 patch set is applied on top of 10.1.4 IM, then you must apply patch 5950169 also, otherwise cloning operations will fail.
In previous 10.1.x releases, database entries in the TNSNAMES.ORA file were created without the domain name.
Disaster Recovery may experience problems with
instantiate topology or other ASG operations if any database entries in the TNSNAMES.ORA file lack domain names.
For example, this entry in the TNSNAMES.ORA file lacks the domain name and could cause problems for Disaster Recovery:
ORCL1 = (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE = yes) (ADDRESS = (PROTOCOL = TCP)(HOST = idmdrtest)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl1.pdx.com) ) ) )
In this case, to prevent problems with Disaster Recovery, add the domain name (PDX.COM) to the TNSNAMES.ORA entry (bolded below):
ORCL1.PDX.COM = (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE = yes) (ADDRESS = (PROTOCOL = TCP)(HOST = idmdrtest)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl1.pdx.com) ) ) )
By adding the domain name to TNSNAMES.ORA file entries, you may be able to avoid error messages such as the following that can occur during an
instantiate topology operation:
>>instantiate topology to voidhost1 idmdrtest.pdx.com 10.196.6.80:7892 (home /home/oracleqa/DREDG/immr10142) HA directory exists for instance im1.idmdrtest.pdx.com HA directory exists for instance orcl1 idmdrtest.pdx.com 10.196.6.150:7892 (home /home/oracleqa/DREDG/immr10142) HA directory exists for instance im1.idmdrtest.pdx.com HA directory exists for instance orcl1 idmdrtest.pdx.com 10.196.6.80:7892 Verifying that the topology is symmetrical in both primary and standby configuration idmdrtest.pdx.com 10.196.6.80:7892 (home /home/oracleqa/DREDG/immr10142) This is primary infrastructure host idmdrtest.pdx.com: -->ASG_DUF-4950: An error occurred on host "idmdrtest.pdx.com" with IP "10.196.6.80" and port "7892" idmdrtest.pdx.com: -->ASG_ORACLE-300: ORA-12560: TNS:protocol adapter error idmdrtest.pdx.com: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: connect email@example.com as sysdba;. idmdrtest.pdx.com: -->ASG_DUF-3502: Failed to connect to database orcl1.pdx.com. idmdrtest.pdx.com: -->ASG_IAS-15753: Error preparing to instantiate the topology on host "idmdrtest.pdx.com" idmdrtest.pdx.com: -->ASG_DUF-3027: Error while executing Instantiating each instance in the topology to standby topology at step - prepare step. >>disconnect
This section describes documentation errata and omissions. It includes the following topics:
create standby database command is not documented. The following information describes this command in more detail.
The syntax for the asgctl
create standby database command is as follows:
create standby database <database_name> on <remote_host>
<database_name> is the primary database unique name used to create the standby database on the remote host system.
<remote_host> is the name of the host system on which the standby database is to be created.
Oracle software and OracleAS Guard software are required to be installed on the node designated as
init.ora parameter file generated for the standby database is configured assuming a non Oracle RAC enabled standby database. If the standby database is to be Oracle RAC enabled, the following initialization parameters must be defined appropriately:
Users should use this command sparingly and only as needed.
When a user connects to an OracleAS Guard server and gets an authentication error even though the correct user name and password were entered, the user should try to put the following flag in the
dsa.conf file in the
/dsa directory and try the operation again:
Note that this DSA configuration file parameter is not documented in the "OracleAS Guard Configuration File Parameters" section of the OracleAS Guard Release Information
When OracleAS Guard issues a create standby database command on Windows if the target standby database environment has not been cleaned up, the following error will occur:
ASG_DGA-12500: Standby database instance "db25" already exists on host <hostame>
To fix this problem, the environment should be cleaned up. The target environment may not be clean because a previous attempted setup of the standby failed for some system reason or because of the operations being attempted to 're-establish' an existing standby database.After cleaning up the environment, the asgctl create standby database command can be reissued. See Section 4.3.1, "Availability of a Previously Undocumented asgctl Command: create standby database" for more information about the asgctl create standby database command.
The following is an example of cleaning up the environment from a command window:
oradim -delete -sid db25
Before performing any OracleAS Guard operations, you must shut down the emagents. This operation is required for OracleAS Guard commands that recycle OracleAS services. You can issue the asgctl run command in a script to perform this operation from within OracleAS Guard. See the OracleAS Disaster Recovery chapters in the Oracle Application Server High Availability Guide for more information.
Otherwise, for example you may get an "ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected" error message.
Shutting down emagents is only described for performing a switchover operation. However, it applies to all OracleAS Guard operations. The documentation will be updated in a future release.
Assuming you already have an existing Disaster Recovery Setup for a 10.1.2.0.0 production database, follow these conceptual steps to apply a 10.1.2.1.0 Disaster Recovery Patchset:
Break the Disaster Recovery setup. Perform an asgctl failover command.
Apply the patch 10.1.2.1.0.
Recreate the Disaster Recovery setup. Perform an asgctl create standby database command followed by an asgctl instantiate topology command. Alternatively, see the Oracle Data Guard documentation for more information about how to reestablish the standby database.
If you attempt to perform an asgctl instantiate topology operation immediately following an asgctl failover operation, an "ORA-01665: control file is not a standby control file" error message is returned.
To work around this problem, you must first perform an asgctl create standby database command to create the standby database on the remote host. See Section 4.3.1, "Availability of a Previously Undocumented asgctl Command: create standby database" for more information about this previously undocumented asgctl command. Also see Section 4.3.5, "Procedure to Patch a 10.1.2.0.0 Disaster Recovery Setup with a 10.1.2.1.0 Patchset" for more information.
When you are running OracleAS Guard in an Oracle RAC environment, you should have only one Oracle RAC instance running while performing OracleAS Guard operations. Otherwise, an error will occur where the primary database will complain that it is mounted by more than one instance, which will prevent a shutdown.
For example, when performing an OracleAS Guard create standby database operation in an Oracle RAC environment with more than one Oracle RAC instance running, the following error will be seen:
ASGCTL> create standby database orcl1 on stanb06v3 . . . This operation requires the database to be shutdown. Do you want to continue? Yes or No y Database must be mounted exclusive stanb06v1: -->ASG_DUF-4950: An error occurred on host "stanb06v1" with IP "188.8.131.52" and port "7890" stanb06v1: -->ASG_DUF-3514: Failed to stop database orcl1.us.oracle.com. stanb06v1: -->ASG_DGA-13002: Error during Create Physical Standby: Prepare-primary processing. stanb06v1: -->ASG_DUF-3027: Error while executing Creating physical standby database - prepare phase at step - primary processing step.