Skip Headers
Oracle® Application Server Release Notes
10g (10.1.4.0.1) for Solaris Operating System (x86) and Solaris Operating System (x86-64)

Part Number B32092-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

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

4 High Availability

This chapter describes issues related to highly available topologies using the OracleAS Disaster Recovery solution. This chapter contains the following issues:

4.1 General Issues and Workarounds

This section describes general issues and workarounds. It includes the following topic:

4.1.1 Upgrade to OracleAS Guard Release 10.1.2.2.1

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:

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

4.1.2 Problem Performing a Clone Instance or Clone Topology Operation

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.

4.1.3 OracleAS Guard Release 10.1.2.1.1 Cannot Be Used with Oracle RAC Databases

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.

4.1.4 OracleAS Guard Returned an Inappropriate Message When It Could Not Find the User Specified Database Identifier

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

4.2 Configuration Issues and Workarounds

This section describes configuration issues and their workarounds. It includes the following topics:

4.2.1 The asgctl shutdown topology Command Does Not Shut Down an MRCA Database That is Detected To Be of a repCa Type Database

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.

4.2.2 Database SIDs Must be the Same for Database Peers at Primary and Standby Sites

The SIDs must be the same for database peers at a primary site and standby site(s) in a Disaster Recovery topology.

4.2.3 Use All Uppercase Characters for Database Initialization Parameters to Avoid Instantiate and Sync Problems

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
"140.87.25.33" 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.

4.2.4 Use the Same Port for ASG on the Production and Standby Sites to Avoid clone instance Operation Problems

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 "140.87.21.201" and port "7890"
stamx11: -->ASG_DUF-3601: Error connecting to server host 152.68.64.213
on port 7890
stamx11: -->ASG_DUF-3512: Error creating remote worker on node 152.68.64.213: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.

4.2.5 Use Fully Qualified Path Names with the add instance Command

As a best practice, use fully qualified path names with the add instance command.

4.2.6 ASG Cloning is Not Supported when the Number of Oracle Homes is Different at the Primary and Standby Hosts

The ASG 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 5.1.3.2 of the Application Server High Availability Guide for release 10.1.3.2.0.

4.2.7 Entries in TNSNAMES.ORA File that Lack Domain Names Cause Disaster Recovery Problems

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 sys/******@orcl1.pdx.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

4.3 Documentation Errata and Omissions

This section describes documentation errata and omissions. It includes the following topics:

4.3.1 Availability of a Previously Undocumented asgctl Command: create standby database

The asgctl 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 <remote_host>.The 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:

  • cluster_database

  • cluster_database_instances

  • remote_listener

Users should use this command sparingly and only as needed.

4.3.2 Connecting to an OracleAS Guard Server May Return an Authentication Error

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.

4.3.3 All emagents Must Be Shut Down Before Performing OracleAS Guard Operations

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.

4.3.4 Procedure to Patch a 10.1.2.0.0 Disaster Recovery Setup with a 10.1.2.1.0 Patchset

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:

  1. Break the Disaster Recovery setup. Perform an asgctl failover command.

  2. Apply the patch 10.1.2.1.0.

  3. 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.

4.3.5 Running Instantiate Topology Across Nodes After Executing a Failover Operation Results in an ORA-01665 Error

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.4, "Procedure to Patch a 10.1.2.0.0 Disaster Recovery Setup with a 10.1.2.1.0 Patchset" for more information.

4.3.6 OracleAS Guard Is Unable to Shutdown the Database Because More Than One Instance of Oracle RAC is Running

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.