Release 2 (8.1.6)
Part Number A76934-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Parallel Server Setup and Configuration Guide Release 2 (8.1.6) Part Number A76934-01 |
|
Specific topics covered in this appendix are:
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:
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.
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:
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, 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 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.
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:
(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 configuration for discovery.
|
Note:
On UNIX operating systems, listeners and instances may also be specified in the db_name inst_sid_list=(op1, op2) lsnr_listener_name="listener_%m"
where |
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:
tnsnames.ora file For example:
op1.us.acme.com= (description= (address=(protocol=tcp)(host=op1-server)(port=1521)) (connect_data= (service_name=op.us.acme.com) (instance_name=op1)))
op.us.acme.com= (description= (load_balance=on) (failover=on) (address_list=(address=(protocol=tcp)(host=op1-server)(port=1521))(address=(protocol=tcp)(host=op2-server)(port=1521)) (connect_data= (service_name=op.us.acme.com)))
sid_startup that uses SID and requests a dedicated server connection in its CONNECT_DATA . For example:
op1_startup.us.acme.com= (description= (address=(protocol=tcp)(host=op1-server)(port= 1521)) (connect_data= (sid=op1) (server=dedicated)))
Discovery results in the creation of:
services.ora file in the $ORACLE_HOME/network/agent directory on UNIX operating systems and ORACLE_HOME\network\admin directory on Windows NT.
The services.ora file should contain an ops_database entry for the Oracle Parallel Server, that lists the node, database address, and name of the database. The example below shows a database named op.us.acme.com running on node op1-server. The database address comes from the op.us.acme.com net service name in the tnsnames.ora file.
op.us.acme.com=(ops_database, op1-server, (description=(load_ balance=on)(failover=on)(address_ list=(address=(protocol=tcp)(host=op1-server) (port=1521))(address=(protocol=tcp)(host=op2-server)(port=1521)))(connect_ data=(service_name=op.us.acme.com)))), op.us.acme.com)
The services.ora file should also contain an OPS_INSTANCE entry for the instance that runs on the node. This entry identifies the:
tnsnames.ora file
The example below shows the instance OP1 runs on node OPSHP1, and is listened for by LISTENER_OPSHP1:
op1.us.acme.com=(ops_instance, op1-server, (description=(address=(protocol=tcp)(host=op1-server)(port=1521))(connect_ data= (service_name=op.us.acme.com)(instance_name=op1))), op.us.acme.com, listener_op1-server)
nmiconf.log in ORACLE_HOME/network/log directory on UNIX operating systems and ORACLE_HOME\network\log directory on Windows NT.
The following message should be ignored:
Warning: No Listener found for sid_db_name, db_name will be skipped.
If the services.ora file contains an ORACLE_DATABASE entry instead of ops_database and ops_instance entries, discovery has failed. To resolve this:
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:
confops.tcl
This entry is created during installation of the Oracle Parallel Server.
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
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
listener.ora and tnsnames.ora file entries to ensure that the required entries are present.
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 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:
$ORACLE_BASE/admin/db_name/bdump on UNIX operating systems
ORACLE_BASE\admin\db_name\bdump on Windows NT
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 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 you do not set the BACKGROUND_DUMP_DEST parameter, the sidalrt.log file is generated in:
$ORACLE_BASE/admin/db_name/bdump on UNIX operating systems
ORACLE_BASE\admin\db_name\bdump on Windows NT
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:
SQL> CONNECT internal/password SELECT pid "Oracle Process Id", name 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
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:
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 © 1996-2000, Oracle Corporation. All Rights Reserved. |
|