Oracle8i Parallel Server Setup and Configuration Guide
Release 8.1.5






Prev Next


Specific topics covered in this appendix are:

Cleaning Up the Registry After an Oracle Database Configuration Assistant Failure on Windows NT

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:

  1. Delete the DB_NAME sub-key in the Performance and Management (P&M) key in the registry on all nodes prior to running the application again:


    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.

  2. Delete the key for OracleServiceSID key in the registry on the node from which the Oracle Database Configuration Assistant was run:


Handling Auto-Discovery Failures

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:

Understanding Auto-Discovery

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.

oratab on UNIX and Registry on Windows NT

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.

Windows NT

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:

Value   Value Type   Description  



Specifies the cluster instance ID data assigned to the OP1 on the first node with the following format:


op1 OPSHP1 opshp1 c:\orant  



Specifies the cluster instance ID data assigned to the OP2 on the second node with the following format:


op2 OPSHP2 opshp2 c:\orant  

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:

The LISTENER.ORA file created after installation typically contains the necessary configuration for auto-discovery. For further information, see "Configuring Net8 for Nodes".


On UNIX platforms, listeners and instances may also be specified in the DB_NAME.CONF file with the inst_sid_list and lsnr_listener_name parameters, as described in "Parameter Descriptions".

inst_sid_list = (op1, op2)
lsnr_listener_name = "listener_%m"

where %m expands to the node name.  


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:

For further information about creating a TNSNAMES.ORA on the managed nodes, see "Step 2: Configure Net Service Names".

Auto-Discovery Results

Auto-discovery results in the creation of:

Troubleshooting Auto-Discovery

If SERVICES.ORA contains an ORACLE_DATABASES entry instead of OPS_DATABASE and OPS_INSTANCE entries, discovery has failed. To resolve this:

  1. Check NMICONF.LST in 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:


    This entry is created during installation of the Oracle Parallel Server Option.

  2. Check to see that the Oracle Parallel Server is defined correctly:

    On UNIX:

    1. Verify oratab and the DB_NAME.CONF file are configured correctly.

    2. Run the following command to verify proper setup:

      setenv ORACLE_PSRV db_name
      opsctl config -C

    On Windows NT:

    1. Check the registry entries associated with the Oracle Parallel Server.

    2. Run the following command to verify proper setup:

      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
  3. Inspect LISTENER.ORA and TNSNAMES.ORA entries to ensure that the required entries are present.

Using Trace Files

This section discusses the following trace file subjects:

Background Thread Trace Files

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 File   Description  


Trace file for BSP process. This trace files shows errors associated with BSP.  


Trace file for the LCKn process. This trace file shows lock request for other background processes.  


Trace file for the LMDn process. This trace file shows lock requests.  


Trace file for the LMON process. This trace file show status of cluster.  


Trace file for the parallel query slaves.  

User Thread 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.

Alert File

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:

Error Call Trace Stack

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:

  1. Obtain the Oracle process ID for the background processes:

    sql> CONNECT internal/password
    SELECT pid "Oracle Process Id", 
        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 
  2. Dump the trace stack to the trace file. For example, to dump out the trace stack of LMON, enter:

    1. Set the Oracle process ID to LMON, which is 3 in this example:

      sql> ORADEBUG setorapid 3 
    2. Dump the error stack to SIDLMON.TRC:

      sql> ORADEBUG dump errorstack 3 

Contacting Oracle Worldwide Customer Support

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:

Severe Errors

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:


Copyright © 1999 Oracle Corporation.

All Rights Reserved.