Oracle® Application Server Release Notes 10g (10.1.4) for Linux x86 Part Number B28193-08 |
|
|
View PDF |
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 5.1.1, "Upgrade to OracleAS Guard Release 10.1.2.2.1"
Section 5.1.2, "Problem Performing a Clone Instance or Clone Topology Operation"
Section 5.1.3, "OracleAS Guard Release 10.1.2.1.1 Cannot Be Used with Oracle RAC Databases"
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:
Section 5.2.2, "Database SIDs Must be the Same for Database Peers at Primary and Standby Sites"
Section 5.2.5, "Use Fully Qualified Path Names with the add instance Command"
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 "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.
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.
As a best practice, use fully qualified path names with the add instance
command.
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.
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
This section describes documentation errata and omissions. It includes the following topics:
Section 5.3.1, "Availability of a Previously Undocumented asgctl Command: create standby database"
Section 5.3.2, "Connecting to an OracleAS Guard Server May Return an Authentication Error"
Section 5.3.3, "All emagents Must Be Shut Down Before Performing OracleAS Guard Operations"
Section 5.3.4, "Procedure to Patch a 10.1.2.0.0 Disaster Recovery Setup with a 10.1.2.1.0 Patchset"
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.
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.
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 5.3.1, "Availability of a Previously Undocumented asgctl Command: create standby database" for more information about this previously undocumented asgctl command. Also see Section 5.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.
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.