| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
 Previous |
 Next |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
Previous |
Next |
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:
Section 14.1.3, "HTTP Server Configuration When Using a Server Load Balancer"
Section 14.1.4, "Problem Performing a Clone Instance or Clone Topology Operation"
Section 14.1.5, "OracleAS Guard Release 10.1.2.1.1 Cannot Be Used with Oracle RAC Databases"
Section 14.1.9, "Problem in an Oracle RAC-non Oracle RAC Environment with Naming Conventions"
Section 14.1.11, "GNU Tar is Required for ASG Clone Topology or Clone Instance Operations"
Section 14.1.12, "ASG Operations Fail if Multiple DB ORACLE_HOMEs Exist on the Same System"
Section 14.1.13, "Known Issue with Disaster Recovery Cloning on Windows"
When using the asgctl add instance command, the OracleAS Guard client must be run from a system that is already included in the topology.
For example, when an OracleAS Guard client is connected to the OracleAS Guard server that is to be added to an existing topology, the following error is returned:
ASG_IAS-15785: ERROR: The topology is missing the instance that exists in the home where the ASG server is running. You must first discover or add the instance in home
The workaround to this problem is to use an OracleAS Guard client from a system that is already included in the topology to perform the asgctl add instance command to add an instance to the topology.
Prior to performing an asgctl switchover operation in an asymmetric topology for instances that do not have a standby peer, you must perform an opmnctl stopall command to shutdown all components on each of these ignored instances on the primary site.
When an XML policy file is in use for an asymmetric topology and has the <instanceList successRequirement ="Ignore" set for an instance, for example, as shown in the following example, then in a switchover operation OracleAS Guard ignores that instance:
. . . <instanceList successRequirement = "Ignore"> <instance>instance B</instance> </instanceList> . . .
OracleAS Guard, on a switchover operation, shuts down all components on the old primary site except for OracleAS Guard and OPMN and ignores instance B because the policy file specifies to do so. The switchover operation fails because all components are not shut down on the primary site, in this case instance B because the policy file specifies to ignore instance B on the primary site, which has no standby peer.
To workaround this problem, the OracleAS Disaster Recovery Administrator must perform an opmnctl stopall operation for all components on instance B prior to the switchover operation in order for the switchover operation to succeed in this asymmetric topology.
If you are using a Server Load Balancer to direct HTTP requests to multiple Oracle HTTP Server instances, Web access to some applications (such as the Application Server Control console and Oracle Web Services Manager) may be redirected to the physical HTTP Server hosts.
To ensure that redirected requests are always sent to the load balancer, configure an Oracle HTTP Server virtual host for the load balancer.
For example, if Oracle HTTP Server is listening on port 7777 and a load balancer called bigip.acme.com is listening on port 80, then consider the following entry in the httpd.conf file:
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName bigip.us.oracle.com Port 80 ServerAdmin youyour.address RewriteEngine On RewriteOptions inherit </VirtualHost>
At the current time, the semantics of an asgctl clone topology operation will not clone databases that are outside of the Oracle Application Server home, thus only the default database installed into the Oracle Application Server 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 using the add instance command to add an Oracle RAC database instance to the topology, the name of the database to use is different on Linux systems than on Windows systems. On Linux systems, the oratab entry is used for discovery of the home and this is done using the database name (dbn). On Windows systems, the system registry is used for discovery of the home, but the database ID (dbid) and not the dbn is located in the registry, so the dbid is used. Consequently, on Windows systems when adding an instance to the topology that is an Oracle RAC database, you must use the database SID name, not the database name when referring to the Oracle RAC database instance.
The Oracle RAC database install on Windows does not store the Oracle RAC DBname or the global DBname anywhere in the registry or oratab. Therefore, the workaround to this problem for Windows systems is as follows. When using the asgctl add instance command, always use the Oracle instance SID of a RAC database and proceed with rest of the Oracle Disaster Recovery cycle of operations, such as create standby database, instantiate topology, sync topology, and switchover topology. For example:
asgctl> add instance <InstanceSID of Oracle RAC> on <virtualhost> asgctl> add instance orcl1 on asinfra.us.oracle.com
In a Windows environment, an error message will be returned directing the user to use the Oracle instance SID of an Oracle RAC database in asgctl commands.
When adding an Oracle RAC instance to the topology using the OracleAS Guard add instance command and 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
Oracle recommends that you shut down the database on the standby site if it is up and running before issuing the asgctl create standby database command; otherwise, the following error is returned:
ASG_DGA-12500: Standby database instance "<instance_name>" already exists on host "<hostname>"
There is a problem with the naming conventions used in the Oracle RAC/non Oracle RAC environment. 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 OracleAS Guard before attempting an asgctl create standby database command; otherwise, the following error message is returned.
ASG_DUF-4902: Object not found in clipboard for key "orcl1keySourceDb".
An error ora-01671 will occur, when attempting to perform an asgctl create standby database operation from a database that is already in 'physical standby' state. An appropriate error message should be echoed indicating that a standby database is already running, rather than returning this error. This is a known issue.
When using the ASG clone topology or clone instance operations, the tar utility is utilized. The target system(s) of these operations must have a version of GNU tar in the default PATH of the system user account in which the standalone ASG install runs.
GNU tar can be obtained at the following location:
http://www.gnu.org/software/tar/
If you have multiple ORACLE_HOME directories on the same system in a disaster recovery setup, the set primary database command fails with the following error:
prodnode1: -->ASG_DUF-4950: An error occurred on host "stama03v1" with IP "XXX.XX.XX.XXX" and port "7890" prodnode1: -->ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor prodnode1: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: connect sys/******@rac as sysdba;. prodnode1: -->ASG_DUF-3502: Failed to connect to database orcl. prodnode1: -->ASG_DUF-3027: Error while executing at step - Default Step. . The database credentials have been set successfully, but they have not been validated
To work around this issue, make sure you have only one database on the system sharing the same inventory for a disaster recovery setup.
If you do not add the directory that contains the jar utility to the PATH when installing a JDK on the standby system, the ASG on the standalone system cannot access the jar.exe utility, and you receive the following error while cloning :
stajx12: -->ASG_SYSTEM-100: operable program or batch file. stajx12: -->ASG_DUF-4040: Error executing the external program or script. The error code is "1" stajx12: -->ASG_IAS-15690: Error running the restore script stajx12: -->ASG_IAS-15698: Error during backup topology operation - copy step stajx12: -->ASG_DUF-3027: Error while executing Clone Instance at step - unpack step.
If you receive this error, add the jar utility to the PATH on the standby system and restart the ASG server.
This section describes configuration issues and their workarounds. It includes the following topics:
Section 14.2.1, "An OracleAS Guard asgctl verify Operation Does Not Check Temp Directories"
Section 14.2.5, "Connecting to an OracleAS Guard Server May Return an Authentication Error"
Section 14.2.7, "All emagents Must Be Shut Down Before Performing OracleAS Guard Operations"
Section 14.2.8, "Procedure to Patch a 10.1.2.0.0 Disaster Recovery Setup with a 10.1.2.1.0 Patchset"
Section 14.2.11, "Add Instance Adds an Instance to Topology with Empty Instancename"
Section 14.2.12, "Create Standby Fails with if Initiated on a Different ASGCTL Shell"
Section 14.2.14, "Heartbeat Failure After Failover in Alert Logs"
Section 14.2.15, "Create Standby Database Fails If Database Uses OMF Storage or ASM storage"
Section 14.2.16, "Database Already Exists Errors During Create Standby"
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.
Therefore, within an environment where an MRCA database has been added to the topology, the database will not be handled by the asgctl shutdown topology command.
In a Disaster Recovery environment that involves Oracle RAC databases, after a switchback operation(switchover topology to <primary site>), the database will be started up on only one of the Oracle RAC nodes by OracleAS Guard; however, the remaining Oracle RAC instances on the primary site must be started up manually.
After performing an asgctl add instance operation from a remote client, it was noted that the instance was being added to the local system rather than to the intended remote system.
As a workaround to this problem, the Disaster Recovery Administrator must first perform an asgctl discover topology operation on the local client system before attempting to perform an asgctl add instance operation to add an instance to the remote system.
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 <ORACLE_HOME>/dsa directory and try the operation again: dsa_realm_override=1.
Note that this DSA configuration file parameter is not documented in the "OracleAS Guard Configuration File Parameters" section of the OracleAS Guard Release Information readme.txt file.
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.
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.
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
"141.86.22.32" 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.
When you create a new database instance using the Database Configuration Assistant (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 instancename in the topology added is empty.
To avoid this problem, make sure the DBName (without domain) and DBSID are the same when creating the database for a Disaster Recovery setup on primary or standby sites.
The create standby database command fails if initiated by ASG clients from any node other than the source primary node where the database resides. To avoid the problem, run the create standby command from the same primary (source) node, where the database for the primary site resides.
For example, if you ran the create standby command from the production database to the standby database where prodnode1 is the primary site database nodename and standbynode1 is its standby database nodename. The ASGCTL shell should always be invoked and connected to prodnode1. If you try to run ASGCTL shell from standbynode1 and connect to prodnode1, the create standby command fails.
If a sync topology command in a RAC-RAC Linux environment fails and you receive missing archive logs errors (as shown below), ping the standby node using tnsping. If you are unable to ping the rstandby node, stop and restart the listener for that node and retry the tnsping.
ASG_SYSTEM_-100: Please resolve missing archived logs and try again.
The following warning appears in the alert logs of the database after a failover scenario, where the new primary database fails to tnsping its remote database instance.
Errors in file c:\oracle\product\10.2.0\admin\orcl\udump\orcl1_rfs_1816.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:11:13 2006 Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl1_arc1_496.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:11:13 2006 PING[ARC1]: Heartbeat failed to connect to standby 'orcl1_remote1'. Error is 16009. Fri Sep 08 09:11:50 2006 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[67]: Assigned to RFS process 628 RFS[67]: Database mount ID mismatch [0x4342404d:0x4341ffb0] Fri Sep 08 09:11:50 2006 Errors in file c:\oracle\product\10.2.0\admin\orcl\udump\orcl1_rfs_628.trc: ORA-16009: remote archive log destination must be a STANDBY database . Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[68]: Assigned to RFS process 2488 RFS[68]: Database mount ID mismatch [0x4342404d:0x4341ffb0] Fri Sep 08 09:12:05 2006 Errors in file c:\oracle\product\10.2.0\admin\orcl\udump\orcl1_rfs_2488.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:12:14 2006 Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl1_arc1_496.trc: ORA-16009: remote archive log destination must be a STANDBY database
To avoid these error messages in the alert logs, null the log_archive_dest_2 parameter using the following commands:
alter system set log_archive_dest_2='SERVICE=null LGWR ASYNC REOPEN=60'; alter system set log_archive_dest_state_2='defer';
The create standby database command fails with ASG_ORACLE-300: ORA-01276 errors if the database storage option uses OMF (Oracle Managed Files) or ASM (Automatic Storage Management).
To work around the problem, create a new database instance using DBCA on the primary site with alternate storage options before running thecreate standby database command.
If you run a create standby command to overwrite an existing database, you get the following error messages:
Checking whether standby instance already exists proddnode1: -->ASG_DUF-4950: An error occurred on host "proddnode1" with IP "a.b.c.d" and port "7891" standbynode1: -->ASG_DUF-4950: An error occurred on host "standbynode1" with IP "e.f.g.h" and port "7891" standbynode1: -->ASG_DGA-12500: Standby database instance "db102" already exists on host "standbynode1". standbynode1: -->ASG_DGA-13001: Error during Create Physical Standby: Prepare-check standby. standbynode1: -->ASG_DUF-3027: Error while executing Creating physical standby database - prepare phase at step - check standby step.
Use the oradim -delete -sid <DBSID> command on Windows, or remove the database entry from oratab on Unix platforms to make sure entries in the standby site for the database do not exist. Now rerun the create standby database to overwrite any existing database successfully.
