| Oracle® Application Server High Availability Guide 10g Release 3 (10.1.3.2.0) Part Number B32201-01 |
|
|
View PDF |
| Oracle® Application Server High Availability Guide 10g Release 3 (10.1.3.2.0) Part Number B32201-01 |
|
|
View PDF |
This appendix describes common problems that you might encounter when deploying and managing Oracle Application Server in high availability configurations, and explains how to solve them. It contains the following topics:
This section describes common problems and solutions in OracleAS Disaster Recovery configurations. It contains the following topics:
Section A.1.2, "Failure to Bring Up Standby Instances After Failover or Switchover"
Section A.1.3, "Switchover Operation Fails At the Step dcmctl resyncInstance -force -script"
Section A.1.4, "Unable to Start Standalone OracleAS Web Cache Installations at the Standby Site"
Section A.1.5, "Standby Site Middle-tier Installation Uses Wrong Hostname"
Section A.1.6, "Failure of Farm Verification Operation with Standby Farm"
Section A.1.12, "Known Issue with Disaster Recovery Cloning on Windows"
Section A.1.15, "Connecting to an OracleAS Guard Server May Return an Authentication Error"
Section A.1.18, "Create Standby Fails if Initiated on a Different ASGCTL Shell"
Section A.1.20, "Heartbeat Failure After Failover in Alert Logs"
Section A.1.21, "Create Standby Database Fails If Database Uses OMF Storage or ASM storage"
Section A.1.22, "Database Already Exists Errors During Create Standby"
Section A.1.24, "An OracleAS Guard asgctl verify Operation Does Not Check Temp Directories"
Section A.1.26, "Instance Name must be Unique Across Hosts in a Topology"
Section A.1.28, "Instantiate Topology Fails if TNS Alias Includes Domain"
Section A.1.29, "ORA-32001 Errors during Create Standby Database"
Section A.1.30, "ORA-09925 Errors when Bringing Up RAC Database Manually after Switchover"
In the OracleAS Disaster Recovery standby site, you may find that the site's OracleAS Metadata Repository is not synchronized with the OracleAS Metadata Repository in the primary site.
Problem
The OracleAS Disaster Recovery solution requires manual configuration and shipping of data files from the primary site to the standby site. Also, the data files (archived database log files) are not applied automatically in the standby site, that is, OracleAS Disaster Recovery does not use managed recovery in Oracle Data Guard.
Solution
The archive log files have to be applied manually. The steps to perform this task is found in Chapter 5, "OracleAS Disaster Recovery".
Standby instances are not started after a failover or switchover operation.
Problem
IP addresses are used in instance configuration. OracleAS Disaster Recovery setup does not require identical IP addresses in peer instances between the production and standby site. OracleAS Disaster Recovery synchronization does not reconcile IP address differences between the production and standby sites. Thus, if you use explicit IP address xxx.xx.xxx.xx in your configuration, the standby configuration after synchronization will not work.
Solution
Avoid using explicit IP addresses. For example, in OracleAS Web Cache and Oracle HTTP Server configurations, use ANY or host names instead of IP addresses as listening addresses
The OracleAS Disaster Recovery asgctl switchover operation requires that the value of the TMP variable be defined the same in the opmn.xml file on both the primary and standby sites.
Problem
OracleAS Disaster Recovery switchover fails at the step dcmctl resyncInstance -force -script and displays a message that a directory could not be found.
Solution
During a switchover operation, the opmn.xml file is copied from the primary site to the standby site. For this reason, the value of the TMP variable must be defined the same in the opmn.xml file on both primary and standby sites; otherwise, the switchover operation will fail. Make sure the TMP variable is defined identically in the opmn.xml files and resolves to the same directory structure on both sites before attempting to perform an asgctl switchover operation.
For example, the following code snippets for a Windows and UNIX environment show a sample definition of the TMP variable.
Example in Windows Environment: ------------------------------- . . . <ias-instance id="infraprod.iasha28.us.oracle.com"> <environment> <variable id="TMP" value="C:\DOCUME~1\ntregres\LOCALS~1\Temp"/> </environment> . . . Example in Unix Environment: ---------------------------- . . . <ias-instance id="infraprod.iasha28.us.oracle.com"> <environment> <variable id="TMP" value="/tmp"/> </environment> . . .
A workaround to this problem is to change the value of the TMP variable in the opmn.xml file on the primary site, perform a dcmctl update config operation, then perform the asgctl switchover operation. This approach saves you having to reinstall the mid-tiers to make use of an altered TMP variable.
OracleAS Web Cache cannot be started at the standby site possibly due to misconfigured. This is applicable only for 10.1.2.x environments and not for 10.1.3.x environments.
Problem
OracleAS Disaster Recovery synchronization does not synchronize standalone OracleAS Web Cache installations.
Solution
Use the standard Oracle Application Server full CD image to install the OracleAS Web Cache component
A middle-tier installation in the standby site uses the wrong hostname even after the machine's physical hostname is changed.
Problem
Besides modifying the physical hostname, you also need to put it as the first entry in /etc/hosts file. Failure to do the latter will cause the installer to use the wrong hostname.
Solution
Put the physical hostname as the first entry in the /etc/hosts file. See Section 5.2.2, "Configuring Hostname Resolution" for more information.
When performing a verify farm with standby farm operation, the operation fails with an error message indicating that the middle-tier machine instance cannot be found and that the standby farm is not symmetrical with the production farm.
Problem
The verify farm with standby farm operation is trying to verify that the production and standby farms are symmetrical to one another, that they are consistent, and conform to the requirements for disaster recovery.
The verify operation is failing because it sees the middle-tier instance as mid_tier.<hostname> and not as mid_tier.<physical_hostname>. You might suspect that this is a problem with the environmental variable _CLUSTER_NETWORK_NAME_, which is set during installation. However, in this case, it is not because a check of the _CLUSTER_NETWORK_NAME_ environmental variable setting finds this entry to be correct. However, a check of the contents of the /etc/hosts file, indicates that the entries for the middle tier in question are incorrect. That is, all middle-tier installations take the hostname from the second column of the /etc/hosts file.
For example, assume the following scenario:
Two environments are used: examp1 and examp2
OracleAS Infrastructure (Oracle Identity Management and OracleAS Metadata Repository) is first installed on examp1 and examp2 as host infra
OracleAS middle-tier (OracleAS Portal and OracleAS Wireless) is then installed on examp1 and examp2 as host node1
Basically, these are two installations (OracleAS Infrastructure and OracleAS middle-tier) on a single node
Updated the latest duf.jar and backup_restore files on all four Oracle homes
Started OracleAS Guard (asgctl) on all four Oracle homes (OracleAS Infrastructure and OracleAS middle-tier on two nodes)
Performed asgctl operations: connect asg, set primary, dump farm
Performed asgctl verify farm with standby farm operation, but it fails because it sees the instance as mid-tier.examp1 and not as mid_tier.node1.us.oracle.com
A check of the /etc/hosts file shows the following entry:
123.45.67.890 examp1 node1.us.oracle.com node1 infra
Then ias.properties and farms shows the following and the verify operation is failing:
IASname=midtier_inst.examp1
However, the /etc/hosts file should actually be the following:
123.45.67.890 node1.us.oracle.com node1 infra
Then ias.properties and farms shows the following and the verify operation succeeds:
IASname=midtier_inst.node1.us.oracle.com
Solution
Check and change the second column entry in your /etc/hosts file to match the hostname of the middle-tier node in question as described in the previous explanation.
A sync farm to operation returns the error message: "Cannot Connect to asdb"
Problem
Occasionally, an administrator may forget to set the primary database using the asgctl command line utility in performing an operation that requires that the asdb database connection be established prior to an operation. The following example shows this scenario for a sync farm to operation:
ASGCTL> connect asg hsunnab13 ias_admin/iastest2 Successfully connected to hsunnab13:7890 ASGCTL> . . . <Other asgctl operations may follow, such as verify farm, dump farm, <and show operation history, and so forth that do not require the connection <to the asdb database to be established or a time span may elapse of no activity <and the administrator may miss performing this vital command. . . . ASGCTL> sync farm to usunnaa11 prodinfra(asr1012): Syncronizing each instance in the farm to standby farm prodinfra: -->ASG_ORACLE-300: ORA-01031: insufficient privileges prodinfra: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: connect null/******@asdb.us.oracle.com as sysdba;. prodinfra: -->ASG_DUF-3502: Failed to connect to database asdb.us.oracle.com. prodinfra: -->ASG_DUF-3504: Failed to start database asdb.us.oracle.com. prodinfra: -->ASG_DUF-3027: Error while executing Syncronizing each instance in the farm to standby farm at step - init step.
Solution
Perform the asgctl set primary database command. This command sets the connection parameters required to open the asdb database in order to perform the sync farm to operation. Note that the set primary database command must also precede the instantiate farm to command and switchover farm to command if the primary database has not been specified in the current connection session.
On Windows systems, if your system PATH environment variable has exceeded the 1024 character limit because you have many Oracle Application Server instances installed or many third party software installations, or both on your system, the asgctl startup command may fail because you are starting the OracleAS Guard server outside of OPMN and the system cannot resolve the directory path.
Problem
Occasionally, on Windows systems with many installations, Oracle Application Server instances or third party software, or both, the asgctl startup command, which is run outside of OPMN, may return a popup error stating it could not find a dynamic link library for a particular file, orawsec9.dll, followed by a DufException. For example:
C:\product\10.1.3\OC4J_1\dsa\bin> asgctl startup
<<Popup Error:>>
The dynamic link library *orawsec9.dll* could not be found.
<<The exception:>>
oracle.duf.DufException
at oracle.duf.DufOsBase.constructInstance(DufOsBase.java:1331)
at oracle.duf.DufOsBase.getDufOs(DufOsBase.java:122)
at
oracle.duf.DufHomeMgr.getCurrentHomePath(DufHomeMgr.java:582)
at oracle.duf.dufclient.DufClient.main(DufClient.java:132)
stado42: -->ASG_SYSTEM-100: oracle.duf.DufException
-----------------------------------------------------------------------------
However, this dll does exist in the ORACLE_HOME\bin directory.
This error is not seen in OracleAS Guard standalone kit because the file orawsec9.dll exists in the ORACLE_HOME\dsa\bin folder.
Solution
The workaround is to either manually edit the system PATH variable with the required path information or manually override the PATH in the command prompt by specifying the relevant %PATH% variables. For example:
C:\set PATH=C:\product\10.1.3\OracleAS_OC4J_2\bin; C:\product\10.1.3\OracleAS_OHS1\jre\1.4.2\bin\client; C:\product\10.1.3\OracleAS_OHS1\jre\1.4.2\bin; C:\product\10.1.3\OracleAS_OHS1\bin;C:\product\10.1.3\OC4J_1\bin C:\product\10.1.3\OC4J_1\dsa\bin> asgctl startup
When using the asgctl add instance command, the OracleAS Guard client must be run from a system that is already included in the topology.
Problem
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 ASGCTL>
Solution
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.
When adding an Oracle RAC instance to the topology using the OracleAS Guard the add instance command and OracleAS Guard can not find the user specified identifier, an inappropriate error message is returned. If the user entered the database name rather that the Oracle instance SID, there is no indication that this is the problem.
Problem
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
Solution
When you encounter the message shown above, be sure you entered the Oracle instance SID, not the database name.
Oracle recommends that you shut down the database on the standby site if it is up and running before issuing the asgctlcreate standby database command.
Problem
If you run the asgctl create standby database command without shutting down the database on the standby site, the following error is returned:
ASG_DGA-12500: Standby database instance "<instance_name>" already exists on host "<hostname>"
Solution
Shut down the database on the standby site if it is up and running before issuing the asgctlcreate standby database command.
For the Windows platform, you must add the directory that contains the jar utility to the PATH when installing a JDK on the standby system.
Problem
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:
standbynode: -->ASG_SYSTEM-100: operable program or batch file. standbynode: -->ASG_DUF-4040: Error executing the external program or script. The error code is "1" standbynode: -->ASG_IAS-15690: Error running the restore script standbynode: -->ASG_IAS-15698: Error during backup topology operation - copy step standbynode: -->ASG_DUF-3027: Error while executing Clone Instance at step - unpack step.
Solution
If you receive this error, add the jar utility to the PATH on the standby system and restart the ASG server.
An inappropriate error is returned when the database is already in a physical standby state.
Problem
An error, ora-01671 occurs 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.
Solution
Ignore the error.
The asgctl shutdown topology command only handles non-database instances.
Problem
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.
Solution
Shut down any repCA type database by alternative methods other than the asgctl shutdown topology command.
An authentication error occurs when trying to connect, even though the correct user name and password were entered.
Problem
When a user connects to an OracleAS Guard server and gets an authentication error even though the correct user name and password were entered.
Note:
This DSA configuration file parameter is not documented in the "OracleAS Guard Configuration File Parameters" section of the OracleAS Guard Release Informationreadme.txt file.Solution
Put the following flag in the dsa.conf file in the <ORACLE_HOME>/dsa directory and try the operation again:
_realm_override=1
After running the asgctl failover operation, you must first perform an asgctl create standby database command to create the standby database on the remote host before performing an asgctl instantiate topology operation.
Problem
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.
Solution
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.
Problem
If you have more than one Oracle RAC instance running while performing OracleAS Guard operations, an error occurs where the primary database complains that it is mounted by more than one instance, which prevents a shutdown. As a result, 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.
Solution
Be sure to have only one Oracle RAC instance running while performing OracleAS Guard operations
The create standby database command fails if initiated by ASG clients from any node other than the source primary node where the database resides.
Problem
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.
Solution
Run the create standby command from the same primary (source) node, where the database for the primary site resides.
The sync topology command in a RAC-RAC Linux environment returns missing archive logs errors.
Problem
The sync topology command in a RAC-RAC Linux environment fails and returns missing archive logs errors (as shown below).
ASG_SYSTEM_-100: Please resolve missing archived logs and try again.
Solution
Ping the standby node using tnsping. If you are unable to ping the standby node, stop and restart the listener for that node and retry the tnsping.
A warning appears in the alert logs of the database after a failover scenario.
Problem
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
Solution
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 with some database storage options.
Problem
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).
Solution
Create a new database instance using DBCA on the primary site with alternate storage options before running the create standby database command.
Error messages appear when attempting to overwrite an existing database.
Problem
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.
Solution
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. Then rerun the create standby database to overwrite any existing database successfully.
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.
Problem
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
Solution
Use the Oracle instance SID of an Oracle RAC database in asgctl commands.
The same TEMP directory structure that exists on a primary site must be set up on the standby site.
Problem
DCM does not work properly when the same TEMP directory structure that exists on a primary site is not set up on the standby site. An OracleAS Guard verify operation does not detect this problem.
Solution
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.
An error occurs when OracleAS Guard issues a create standby database command on Windows and the target standby database environment has not been cleaned up.
Problem
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 occurs:
ASG_DGA-12500: Standby database instance "db25" already exists on host <hostame>
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.
Solution
Clean up the environment using the following command.
oradim -delete -sid db25
After cleaning up the environment, the asgctl create standby database command can be reissued.
If you have multiple nodes in the topology on the primary site, then the instance name of each Oracle Application Server tier needs to be unique across all the homes on all the nodes in the primary site.
Problem
If the instance name of each Oracle Application Server tier is not unique across all the homes on all the nodes in the primary site, when you execute an add instance command for the second instance with the same instance name as an already added instance, you get the following error:
ASGCTL> add instance ohs on primaryhost1 ASGCTL> add instance ohs on primaryhost2 host2: -->ASG_IAS-15782: Error: Instance "ohs" already exists in the topology ASGCTL>
Solution
Make sure each Oracle Application Server tier has a unique name across all the homes on all the nodes in the primary site.
A misleading message appears under the Instances and Properties tab of the Java SSO Configuration page.
Problem
When you use Application Server Control to configure Java Single Sign-On (Java SSO), the following message appears at the top of the Java SSO Configuration page if no Java SSO applications are running in the cluster:
There are no active Java SSO applications in the cluster. At least one Java SSO application (javasso) must be running before you can configure Java SSO.
However, the following additional and misleading message appears under the Instances and Property tab in the Java SSO Configuration page:
Java SSO is configured for this cluster.
Solution
When an error message appears at the top of the Java SSO Configuration page, ignore the message that appears under the Instances and Properties tab. In fact, Java SSO cannot be configured until at least one instance of the Java SSO application is running in the cluster.
For more information, see "OC4J Java Single Sign-On" in the Oracle Application Server Containers for J2EE Security Guide
Instantiate topology fails with if the TNS alias entries for the standby database include the domain.
Problem
The following errors are returned when the TNS alias entries for the standby database include domain:
ORCL.ORACLE.COM = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standbynode.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL.ORACLE.COM) ) ) . ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service@ requested in connect descriptor
Solution
Add the correct domain to the NAMES.DEFAULT_DOMAIN parameter in sqlnet.ora on the standby database before running the instantiate command.
In Windows operating systems, errors are returned after executing the create standby database command.
Problem
The create standby database command creates the SPFILE under ORACLE_HOME/dbs directory on the standby instead of ORACLE_HOME/database. As a result, the whenever the database is started up on the standby site, it fails to use the SPFILE under ORACLE_HOME/dbs and uses pfile instead. When the create standby command is executed again from standby site (for role reversal) it fails because the database does not use spfile.
stanbynode1: -->ASG_DUF-4950: An error occurred on host "stada26" with IP "140.87.5. @ 102" and port "7892" standbynode1: -->ASG_ORACLE-300: ORA-32001: write to SPFILE requested but no SPFILE specified at startup standbynode1: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: alter sys tem set db_file_name_convert= 'C:\WORK\ORADATA\ASDB01','C:\WORK\ORADATA\ASDB01' SCOPE=SPFILE /* ASG_DGA */;. standbynode1: -->ASG_DGA-13010: Error during Create Physical Standby: Finish-configure primary. standbynode1: -->ASG_DUF-3027: Error while executing Creating physical standby database - finish phase at step - finish step. ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Solution
On Windows only, after executing the create standby database command, copy the SPFILE from ORACLE_HOME/dbs to ORACLE_HOME/database on the standby database site.
ORA-09925 errors appear when bringing up a RAC database manually after a switchover operation.
Problem
The following errors appear after a ASG switchover operation, when bringing up some of the RAC database instances manually.
SQL> startup; ORA-09925: Unable to create audit trail file Linux Error: 2: No such file or directory Additional information: 9925
Solution
Make sure the directory pointed by audit_file_dest parameter in your init file exists.
For example:
mkdir <ORACLE_HOME>/admin/<dbname>/admin
This section describes common problems and solutions for middle-tier components in high availability configurations. It contains the following topics:
Section A.2.1, "Using Multiple NICs with OracleAS Cluster (OC4J-EJB)"
Section A.2.2, "Performance Is Slow When Using the "opmn:" URL Prefix"
Problem
If you are running OracleAS Cluster (OC4J-EJB) on computers with two NICs (network interface cards) and you are using one NIC for connecting to the network and the second NIC for connecting to the other node in the cluster, multicast messages may not be sent or received correctly. This means that session information does not get replicated between the nodes in the cluster.
Figure A-1 OracleAS Cluster (OC4J-EJB) Running on Computers with Two NICs
Solution
You need to start up the OC4J instances by setting the oc4j.multicast.bindInterface parameter to the name or IP address of the other NIC on the node.
For example, using the values shown in Figure A-1, you would start up the OC4J instances with these parameters:
On node 1, configure the OC4J instance to start with up with this parameter:
-Doc4j.multicast.bindInterface=123.45.67.21
On node 2, configure the OC4J instance to start with up with this parameter:
-Doc4j.multicast.bindInterface=123.45.67.22
You specify this parameter and its value in the "Java Options" field in the "Command Line Options" section in the Server Properties page in the Application Server Control Console (Figure A-2).
Figure A-2 Server Properties Page in Application Server Control Console
Problem
If you have applications that use the "opmn:" prefix in their Context.PROVIDER_URL property, you may experience slow performance in the InitialContext method.
The following sample code sets the PROVIDER_URL to a URL with an opmn: prefix.
Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL, "opmn:ormi://hostname:port/cmpapp"); // ... set other properties ... Context context = new InitialContext(env);
If the host specified in PROVIDER_URL is down, the application has to make a network connection to OPMN to locate another host. Going through the network to OPMN takes time.
To avoid making another network connection to OPMN to get another host, set the oracle.j2ee.naming.cache.timeout property so that the values returned from OPMN the first time are cached, and the application can use the values in the cache.
The following sample code sets the oracle.j2ee.naming.cache.timeout property.
Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL, "opmn:ormi://hostname:port/cmpapp"); // set the cache value env.put("oracle.j2ee.naming.cache.timeout", "30"); // ... set other properties ... Context context = new InitialContext(env);
Table A-1 shows valid values for the oracle.j2ee.naming.cache.timeout property:
Table A-1 Values for the oracle.j2ee.naming.cache.timeout Property
| Value | Meaning |
|---|---|
|
|
No caching. |
|
|
Cache only once, without any refreshing. |
|
Greater than |
Number of seconds after which the cache can be refreshed. Note that this is not automatic; the refresh occurs only when you invoke " If the property is not set, the default value is 60. |
With the property set, you will still see some delay on the first "new InitialContext()" call, but subsequent calls should be faster because they are retrieving data from the cache instead of making a network connection to OPMN.
Note that for optimal performance, you should also set Dedicated.Connection to either YES or DEFAULT, and set Dedicated.RMIcontext to FALSE.
In case the information in the previous section is not sufficient, you can find more solutions on Oracle MetaLink, http://metalink.oracle.com. If you do not find a solution for your problem, log a service request.
See Also:
Oracle Application Server Release Notes, available on the Oracle Technology Network: http://www.oracle.com/technology/documentation/index.html
