Oracle8i Parallel Server Setup and Configuration Guide
Release 2 (8.1.6)

Part Number A76934-01





Go to previous page Go to next page


Specific topics covered in this appendix are:

Resolving Service Discovery Failures

Discovery of nodes and objects by Oracle Enterprise Manager typically fails because the Oracle Intelligent Agent was not starting on the node or the configuration is incorrect. If starting the Oracle Intelligent Agent does not resolve the problem, the discovery failure may be due to a more serious configuration issue.

This section covers the following topics:

Understanding Discovery

To understand proper configuration, it is important to understand how discovery works. During discovery, a services.ora file on the managed nodes is created in the $ORACLE_HOME/network/agent directory on UNIX operating systems 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:

You must accurately configure each of these components in order for discovery to work correctly.

oratab on UNIX and Registry on Windows NT

Discovery first discovers the Oracle Parallel Server database name and the nodes associated with the database. How it accomplishes this depends on whether the managed system is running on:


On UNIX operating systems, 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:


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, 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:


On some operating systems, such as Sun Solaris, 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 has no entries.

Windows NT

The registry lists all Oracle Parallel Servers that run on a node under the subkey HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OSD\PM. Under this subkey, each Oracle Parallel Server cluster has its own registry subkey, as described in "Registry Values for Oracle Parallel Server Database on Windows NT".

Oracle Enterprise Manager uses information to discover the Oracle Parallel Server database name, its instances and nodes. Once the instances and nodes are discovered, the listener.ora and tnsnames.ora files are inspected.


Discovery locates the listener and instance names for a node with the listener.ora file, located in $ORACLE_HOME/network/admin on UNIX operating systems and ORACLE_HOME\network\admin on Windows NT on the discovered nodes.

Discovery requires the following entries:

The listener.ora file created after installation typically contains the configuration for discovery.

See Also:

"Listener (listener.ora file)" 


On UNIX operating systems, 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)

where %m expands to the node name. 


The tnsnames.ora file, located in $ORACLE_HOME/network/admin on UNIX operating systems and ORACLE_HOME\network\admin on Windows NT on the discovered nodes, is read by the discovery process to determine names and address information for the Oracle Parallel Server and instances on a node.

Discovery requires the following entries:

Discovery Results

Discovery results in the creation of:

Troubleshooting Discovery

If the services.ora file contains an ORACLE_DATABASE 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 operating systems and ORACLE_HOME\network\agent\config directory on Windows NT. This file contains a list third-party discovery scripts to run. It must contain at least the following entry:


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

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

    On UNIX:

    1. Verify that 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

    On UNIX, OPSCTL displays the name of the node, instance, and listener for the node. The following example shows a node named NODE1 running an instance named OP1 with a listener named LISTENER_NODE1.

    node1 op1 listener_node1
    On Windows NT, OPSCTL displays a list of all nodes and their corresponding 
    instances. For example:
    node1 op1
    node2 op2
    node3 op3
  3. Inspect the listener.ora and tnsnames.ora file 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 the BACKGROUND_DUMP_DEST parameter is set in the initdb_name.ora initialization parameter file. If you set BACKGROUND_DUMP_DEST, the trace files are stored in the directory specified. If you do not set the parameter, the trace files are stored in:

The 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 Cache Fusion BSP (Block Server Process). This trace files shows errors associated with BSP. 


Trace file for the LCKn process. This trace file shows lock requests 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 shows the status of the cluster. 


Trace file for the parallel execution processes. 

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 you do not set the BACKGROUND_DUMP_DEST parameter, 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 a 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; 

    The output displayed should resemble the following:

    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 the trace stack of LMON, enter:

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

      ORADEBUG setorapid 3 
    2. Dump the error stack to sidlmon.trc:

      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 available:

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:

Go to previous page Go to next page
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.