Release 8.1.5
A67439-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Parallel Server Setup and Configuration Guide Release 8.1.5 A67439-01 |
|
Specific topics covered in this appendix are:
If the Oracle Database Configuration Assistant fails during the creation of a database on Windows NT, certain entries may have been installed in the registry. When a database fails:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OSD\PM
\DB_NAME
If you do not delete this key, the Oracle Database Configuration Assistant will assume the db_name database name is already in use. The next time you run the Oracle Database Configuration Assistant, you will not be able to use this database name, even though the raw devices will expect it.
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\OracleServiceSID
Auto-discovery of nodes or objects in the Console typically fails because Oracle Intelligent Agent was not being started on the node or the configuration is incorrect. If starting the Oracle Intelligent Agent does not resolve the problem, it may be a more serious configuration issue.
This section covers the following topics:
To understand proper configuration, it is important to understand how auto-discovery works. During the auto-discovery process, a SERVICES.ORA file on the managed nodes is created in the $ORACLE_HOME/network/agent directory on UNIX platforms and ORACLE_HOME\network\admin directory on Windows NT. This file contains information about the nodes and their services (databases, instances and listeners) discovered.
This file is created from the following sources, all on the managed nodes:
Each of these components must be configured correctly in order for auto-discovery to work correctly.
Auto-discovery first discovers the Oracle Parallel Server database name and the nodes associated with the database. How it accomplishes this is dependent on whether the managed system is running on:
On UNIX platforms, auto-discovery uses information in the oratab entry for the name of the Oracle Parallel Server. oratab is found in /etc/oratab or /var/opt/oracle/oratab. It contains entries of the form:
db_name: oracle_home:N
where db_name is the database name and oracle_home is the Oracle home given to your Oracle Parallel Server database. From this entry, the database name is acquired.
Next, auto-discovery looks for the node_list parameter in DB_NAME.CONF file, located in $ORACLE_HOME/ops, to determine which nodes run instances of the Oracle Parallel Server:
node_list = "1,2,3"
On some platforms node_list defaults to the entire cluster, and this parameter does not need to be explicitly set. The configuration file must exist even if it is empty.
The registry lists all Oracle Parallel Servers that run on a node under HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OSD\PM. Under this subkey, each Oracle Parallel Server cluster has its own registry subkey:
The domain key name is the same as the cluster name. Within these keys, values are defined to provide the per-domain and per-instance information.
The following are the registry entries required for auto-discovery:
During auto-discovery, the information in the registry yields a list of instances and nodes. Only instances that run on the local node are discovered. Once the instances and nodes are discovered, the LISTENER.ORA and TNSNAMES.ORA files are inspected.
Auto-discovery locates the listener and instance names for a node with the LISTENER.ORA file, located in $ORACLE_HOME/network/admin on UNIX platforms and ORACLE_HOME\network\admin on Windows NT on the discovered nodes.
Auto-discovery requires the following entries:
(description = (address = (protocol = tcp)(host = opshp1-pc)(port = 1521)) )
sid_list_listener = (sid_list = (sid_desc = (sid_name = op1) ) )
The LISTENER.ORA file created after installation typically contains the necessary configuration for auto-discovery. For further information, see "Configuring Net8 for Nodes".
|
Note:
On UNIX platforms, listeners and instances may also be specified in the DB_NAME.CONF file with the inst_sid_list = (op1, op2) lsnr_listener_name = "listener_%m"
where |
The TNSNAMES.ORA file, located in $ORACLE_HOME/network/admin on UNIX platforms and ORACLE_HOME\network\admin on Windows NT on the discovered nodes, is consulted by auto-discovery to determine names and address for the Oracle Parallel Server and instances on a node.
Auto-discovery requires the following entries:
Shown below is instance OP1 defined:
op1 = (description = (address = (protocol = tcp) (host = opshp1) (port = 1521)) (connect_data = (service_name = op.us.oracle.com) (instance_name = op1))
Shown below is database OP defined, as described in "Creating An Entry in the TNSNAMES.ORA File for the Database and Enabling Client Load Balancing":
op =
(description=
(address=
(protocol = tcp)
(host = opshp1)
(port = 1521))
(connect_data=
(service_name=op.us.oracle.com)))
SID_startup that uses SID= in its CONNECT_DATA, as described in "Additional Configuration Required for Windows NT in the TNSNAMES.ORA File".
op1_startup = (description = (address = (protocol = tcp) (host = opshp1) (port = 1521)) (connect_data = (sid = op1))
For further information about creating a TNSNAMES.ORA on the managed nodes, see "Step 2: Configure Net Service Names".
Auto-discovery results in the creation of:
$ORACLE_HOME/network/agent directory on UNIX platforms and ORACLE_HOME\network\admin directory on Windows NT.
The SERVICES.ORA file should contain an OPS_DATABASE entry for the Oracle Parallel Server, which lists the node, database address, and name of the database. The example below show a database named OP.US.ORACLE.COM running on node OPSHP1. The database address comes from a OP.US.ORACLE.COM net service name in the TNSNAMES.ORA file.
op.us.oracle.com = (ops_database, opshp1, (description_ list=(description=(address=(protocol=tcp) (host=opshp1) (port=1521)) (connect_data=(sid=op1))) (description=(address=(protocol=tcp) (host=opshp2) (port=1521)) (connect_data=(sid=op2)))), op.us.oracle.com)
The SERVICES.ORA file should also contain an OPS_INSTANCE entry for the instance that runs on the node. This entry identifies the:
The example below shows the instance OP1 runs on node OPSHP1, and is listened for by LISTENER_OPSHP1:
op1.us.oracle.com = (ops_instance, opshp1, (description=(address_ list=(address=(protocol=tcp) (host=opshp1) (port=1521))) (connect_ data=(sid=op1))), op.us.oracle.com, listener_opshp1)
ORACLE_HOME/network/log directory on UNIX platforms and ORACLE_HOME\network\log directory on Windows NT.
The following message types should be ignored:
Warning: No Listener found for SID_db_name, db_name will be skipped.
If SERVICES.ORA contains an ORACLE_DATABASES entry instead of OPS_DATABASE and OPS_INSTANCE entries, discovery has failed. To resolve this:
ORACLE_HOME/network/agent/config directory on UNIX platforms and ORACLE_HOME\network\agent\config directory on Windows NT. This file contains a list third-party auto-discovery scripts to run. It must contain at least the following entry:
confops.tcl
This entry is created during installation of the Oracle Parallel Server Option.
On UNIX:
oratab and the DB_NAME.CONF file are configured correctly.
setenv ORACLE_PSRVdb_nameopsctl config -C
On Windows NT:
opsctl config -ndb_name
OPSCTL displays the name of the node, instance and listener for the node. The example below shows a node named NODE1 running an instance named OP1 with a listener named LISTENER_NODE1.
node1 op1 listener_node1
This section discusses the following trace file subjects:
Oracle Parallel Server background threads use trace files to record occurrences and exceptions of database operations, as well as errors. These detailed trace logs are helpful to Oracle support to debug problems in your cluster configuration. Background thread trace files are created regardless of whether or not the BACKGROUND_DUMP_DEST parameter is set in the INITDB_NAME.ORA initialization parameter file. If BACKGROUND_DUMP_DEST is set, the trace files are stored in the directory specified. If the parameter is not set, the trace files are stored in:
Oracle8i database creates a different trace file for each background thread. The name of the trace file contains the name of the background thread, followed by the extension .TRC, such as:
Oracle Parallel Server trace information is reported in the following trace files:
Trace files are also created for user threads if the USER_DUMP_DEST parameter is set in the initialization parameter file. The trace files for the user threads have the form ORAXXXXX.TRC, where XXXXX is a 5-digit number indicating the process ID on UNIX or the Windows NT thread ID.
The alert file, SIDALRT.LOG, contains important information about error messages and exceptions that occur during database operations. Each instance has one alert file; information is appended to the file each time you start the instance. All threads can write to the alert file.
SIDALRT.LOG is found in the directory specified by the BACKGROUND_DUMP_DEST parameter in the INITDB_NAME.ORA initialization parameter file. If the BACKGROUND_DUMP_DEST parameter is not set, the SIDALRT.LOG file is generated in:
Oracle Worldwide Support may ask you to create an error call trace stack for a particular trace file. An error call trace stack provides program trace of specific background or user threads in the database.
To create an error call trace:
sql> CONNECT internal/password SELECT pid "Oracle Process Id", name from v$process, v$bgprocess where v$process.addr = v$bgprocess.paddr;
Output displayed looks like this:
Oracle Pro NAME ---------- ----- 2 PMON 3 LMON 4 LMD0 5 DBW0 6 LGWR 7 CKPT 8 SMON 9 RECO 10 SNP0 11 SNP1 13 LCK0
If after reading this appendix, you still cannot resolve your problems, call Oracle Worldwide Customer Support to report the error. Please have the following information at hand:
If an ORA-600 error occurred, it will be printed to SIDALRT.LOG file. If an ORA-600 error or any other severe errors appear in the SIDALRT.LOG file, then provide all files in:
