B
Troubleshooting

This chapter covers generic troubleshooting strategies in the event your Intelligent Agent does not function properly. The following topics are discussed:

Troubleshooting the Intelligent Agent

Under most circumstances, the Intelligent Agent itself requires very little in the way of configuration. In order to function properly, however, the Agent must be able to communicate with the managing host and managed services. If you are familiar with Oracle and your operating system, using the following abbreviated checklists will likely solve problems that can interfere with Agent operation.

Important:

Because the Agent is continuously being improved from one release to the next, it is strongly recommended that you upgrade to the latest Agent available for your particular server release. Oftentimes, this will resolve problems you may encounter with earlier versions of the Agent. In general, the lowest acceptable version of the Agent should be compatible with the highest version of the software being monitored.

Quick Checks

The following checklists cover the areas most likely to affect Agent operation. Agent troubleshooting checklists have been divided according to the two most common platforms on which the Agent is run: Windows NT and UNIX. The checklists are abbreviated and assume knowledge of both Oracle, the operating system, and related communication protocols. Specific troubleshooting procedures are covered in detail later in this chapter.

Quick Checks for the Windows NT Agent

If you are running an Agent on a Windows NT system, use the following checklist.

Make sure the Agent service is up by checking the OracleAgent service in your control panel. If the Agent did not start up, use any of the following hints listed below.
Check for messages written to the NT Event Viewer (under Administrative Tools) since this is where the NT Agent writes any problems associated with startup.
Check if snmp_ro.ora, snmp_rw.ora, and services.ora are created by the Agent on startup. snmp_ro.ora and snmp_rw.ora are in the ORACLE_HOME\network\admin directory, and services.ora is in the ORACLE_HOME\network\agent directory.

Compare the services listed with the services which are available on the machine. Please refer to Appendix A, "Agent Configuration Files" for valid sample files.

If services are missing, check the following files for inconsistency or corruption:
- listener.ora
- tnsnames.ora

If you have upgraded the database software and one of your machines is having problems with the generated snmp_ro.ora, snmp_rw.ora or services.ora file, follow the instructions below:

Run catsnmp.sql under the INTERNAL or SYS account (NOT the dbsnmp account). Normally the catsnmp.sql script is run from catalog.sql upon database creation but since this is an upgrade, you may not have run this script yet. If the necessary scripts have not been run, the dbsnmp account is not created.

Important:

When installing a 9i Agent on a machine running a pre-9i database, you must re-run a version specific copy of catsnmp.sql which is located in the ORACLE_HOME/sysman/admin directory of the 9i Enterprise Manager client install. For example, if you are running Oracle 8.1.7 on a machine and then install a 9i Agent, you must re-run the catsnmp_8i.sql script after installing the new Agent. This operation must be performed for each pre-9i database serviced by this Agent.

Do not run the 9i version of the catsnmp.sql script against pre-9i databases.

If you have more than one SID or older SIDs referenced in the oratab file, run catsnmp.sql against each of the databases.
The snmp_ro.ra file is a read only file which means that all changes to the file will be overwritten each time the Agent is started. You can make changes (if needed) to the snmp_rw.ora file.

If you are trying to do backups, you must run backupts.sql with the dbsnmp/dbsnmp account.

Warning:

Do not modify the Tcl scripts (job and events scripts written in Tool Command Language) that come with the Agent. If you want to submit a job different from the ones that are predefined with the Agent, use the TCL Job where you are allowed to pass in arbitrary scripts and have the Agent execute them.

Check that you do not have a system path set to external drives.

The Agent is a service and runs by default as SYSTEM. It also needs DLLs from the ORACLE_HOME/BIN directory. If you need mapped drives in your path, you MUST NOT set them in the SYSTEM path.

To set your own path:
1. Move mapped drive paths out of SYSTEM path variables and into your own.
2. Reboot to "unset" the systems path.
If you still do not know why the Agent did not start, trace the Agent.
1. Set the following variables in snmp_rw.ora:
  
  dbsnmp.trace_level=admin (or 16 if you want maximum information)
  
  dbsnmp.trace_directory=<any directory in which the Oracle user has write privileges>
  
  dbsnmp.trace_file=<name of the trace output file>
  
  dbsnmp.trace_unique=true/false (When TRUE, this parameter generates a unique trace file each time.)
2. Restart the Agent.
3. Check the log files located in the oracle_home/network/log directory.
  
  DBSNMP.LOG should show general Agent problems.
  
  DBSNMP.NOHUP should show any errors related to the Agent's "watchdog" dbsnmpwd process.
  
  NMICONF.LOG should show problems with auto-discovery.
Ensure that the DNS Host entry is set to the node name in the listener.ora and tnsnames.ora files.
1. Run the start button-> settings-> control panel-> network-> protocol-> TCP/IP properties.
2. Check the DNS Host entry.
Check if you have TCP/IP installed. TCP/IP is a requirement.

Quick Checks for UNIX Agents

If you are running an Agent on a UNIX system, use the following checklist.

Make sure requisite system requirements are met:
- TCP/IP is configured correctly
- Valid ORATAB file for your Oracle environment.
Check the Agent's status. Enter the command:
```
agentctl status
```
Alternatively, you can check to see if the Intelligent Agent is running by entering the following command:
```
ps -eaf | grep dbsnmp
```
These checks should show that a "dbsnmp" process is running and/or "dbsnmpwd" watchdog script is running.
Check the ORACLE_HOME/network/log/dbsnmp*.log file for errors on UNIX. (nmiconf.log for discovery).
Check that the Oracle user has write permissions to the following directories:
- ORACLE_HOME/network/log
- ORACLE_HOME/network/trace
- ORACLE_HOME/network/agent
- ORACLE_HOME/network/agent/jobout
Check snmp_ro.ora, snmp_rw.ora, and services.ora for the entries created by the Agent. snmp_ro.ora and snmp_rw.ora are in the ORACLE_HOME/network/admin directory, and services.ora is in the ORACLE_HOME/network/agent directory. Alternatively, you can check the directory pointed to by the TNS_ADMIN environment variable.

Compare the services listed with the services which are available on the machine. Please refer to Appendix A, "Agent Configuration Files" for valid sample files.

If services are missing, check the following files for inconsistency or corruption:
- listener.ora
- tnsnames.ora
- oratab

If you have upgraded the database software and one of your machines is having problems with the generated snmp_ro.ora, snmp_rw.ora or services.ora file, follow the instructions below:

Important:

Do not run the 9i version of the catsnmp.sql script against pre-9i databases.

If you have more than one SID or older SIDs referenced in the oratab file, run catsnmp.sql against each of the databases.
The snmp_ro.ra file is a read only file which means that all changes to the file will be overwritten each time the Agent is started. You can make changes (if needed) to the snmp_rw.ora file.

If you are trying to do backups, you must run backupts.sql with the dbsnmp/dbsnmp account.

Warning:

If you have problems running the Intelligent Agent control utility (agentctl), set tracing for agentctl as follows:
- agentctl.trace_level=admin
- agentctl.trace_directory
- agentctl.trace_file
If you still do not know why the Agent did not start, trace the Agent by setting the following variables in snmp_rw.ora and then re-start the Agent.
- dbsnmp.trace_level=admin (or 16 if you want more information)
- dbsnmp.trace_directory=<any directory which the Oracle user can write to>
- dbsnmp.trace_file=agent

Additional Checks

If after going through the quick checks your Intelligent Agent still is not functioning correctly, use the following section to cover other areas of Agent operation that are less probable causes of Agent operating problems. In addition, many of the steps in the checklists are covered in greater detail for those users who may be less familiar with Oracle and/or the operating system on which the Agent is running. The following questions are covered in this section:

Is TCP/IP configured and running correctly?
Do the DNS Name and the Computer Name Match? (Windows NT)
Are the Oracle Net Configuration files correct?
Is Oracle Net functioning properly?
Did the Agent startup successfully?
Did the Agent connect to ALL instances on its node?
Is the Agent running with the correct permissions? (UNIX)

Does the OS user exist and does it have the correct permissions? (Windows NT)

Note:

You do not need to remove all ".q" files from the $ORACLE_HOME/network/agent directory in order to debug the Agent. Although this approach was recommended in the past, troubleshooting more recent versions of the Intelligent Agent no longer requires this action. There are exceptions to this rule, which will be pointed out later in the chapter.

Is TCP/IP configured and running correctly?

One of the most common problems that prevents the Agent from starting is TCP/IP configuration. To check whether your TCP/IP setup is configured correctly, issue the following commands at the command line:

Determine if the host machine (machine on which the Agent runs) and the specified network IP address refer to the same machine. Type the following at the command line.
1. ping <hostname>
2. ping <IP address>
3. Check to see if the above commands return the same information (Windows NT). For UNIX systems, you should see "<hostname> is alive" and "<IP address> is alive" respectively.
Determine if the host machine is reachable by issuing the following command.

telnet <hostname>
Validate whether the host machine is available on the local network and whether the machine on which you are running the Management Server can access the host machine.
1. ping the machine running the Agent using its IP address from itself .
2. ping the machine running the Agent using its IP address from the machine running the Management Server.
Determine if the machine running the Management Server is available on the local network and whether the machine running the Agent can communicate with the machine running the Management Server.
1. ping <IP address of the console machine>
  
  Ping the machine running the Management Server from itself.
2. ping <IP address of the Management Server machine>
  
  Ping the Management Server machine from the machine running the Agent
3. Check to see if the steps above return the same information.
  
  Note:
  To determine the hostname of a Windows NT system, type "hostname" at a command prompt.

Correcting TCP/IP configuration problems

(Windows NT) Edit the WINNT\system32\drivers\etc\hosts and lmhosts files.

If these files have never been used, only sample files will exist in the directory. Either rename or copy the .sam files to just the file name with no extension.

(UNIX) Log in as root and edit the /etc/hosts file.

NIS/DNS setups may require modification at the NIS/DNS level to correct TCP/IP configuration problems.
Verify that the IP address and host information for each system are correct.

Example: (Windows NT)
```
HOSTS file: 
        122.111.111.111   myHost

LMHOSTS file: 
        122.111.111.111   myHost  #PRE
```
Note:
You can also verify this information through the Windows NT Control Panel -> Network property sheet.

Delete the $ORACLE_HOME\network\agent\*.q and services.ora files.

Note:

The *.q files are binary files containing information about Agent state and current jobs and events. Do not delete these files without first removing all jobs and events registered against this Agent. Because the hostname of the machine on which the Agent is running on is used to encrypt the 'Q' files, these files cannot be copied from one system to another.

Delete the $ORACLE_HOME\network\admin\snmp_ro.ora and

    $ORACLE_HOME\network\admin\snmp_rw.ora files.

Restart the Agent.

Do the DNS Name and the Computer Name Match? (Windows NT)

Before Release 8.0.4 of the Agent, the NT Agent required the DNS Hostname and the Computer Name to be identical. These parameters can be checked/changed from the following Windows NT Control Panel property sheets.

To verify the computer name:

Control Panel --> Network --> Identification --> Computer Name

To verify the DNS Name:

Control Panel --> Network --> Protocols --> TCP/IP Protocol --> Properties-->DNS --> Hostname

Are the Oracle Net Configuration files correct?

In addition to proper network configuration, which allows nodes in your network to communicate, components of your Oracle environment must also be able to communicate with each other. Oracle Net provides the session and data communication medium between client machines and Oracle servers, or between Oracle servers. For this reason, proper Oracle Net configuration is a prerequisite for Agent communication. This section covers the most common problems that can occur when Agent communication fails.

Oracle Net configuration files are found in either the $TNS_ADMIN location or the $ORACLE_HOME/network/admin directory (both UNIX and NT).

Primary configuration files are:

listener.ora
sqlnet.ora
tnsnames.ora

See Appendix A, "Agent Configuration Files" for information and examples of the above files.

TNS_ADMIN variable usage during Agent Discovery

(UNIX)

All versions of the Unix discovery script allow the use of the TNS_ADMIN variable to locate input files (listener.ora and tnsnames.ora). Only Agent versions 7.3.4 and above correctly write the output files (snmp_ro.ora and snmp_rw.ora) into TNS_ADMIN, if set.

(Windows NT)

Beginning with version 8.0.5, the discovery script also reads the TNS_ADMIN value from the NT Registry.

The Agent also uses the TNS alias information found in the listener.ora file. The Agent does so even within an Oracle names environment. This behavior is intentional since an Oracle Names server may be temporarily unavailable and the Agent needs to be able to resolve names at all times. Check the following to make sure the local translation of the TNS alias takes place:

Verify the listener.ora file has at least one TCP entry configured for the target.

Do not activate the listener on port 1748, since Agent is listening on this port. (This is the reason you can use TNSPING against the Agent; TNSPING cannot differentiate between a listener and an Agent)
Ensure that the DNS Host entry is set to the node name in the listener.ora and tnsnames.ora files.
1. From the Windows NT menu bar, click Start -> Settings -> Control Panel
2. Double-click on the Network icon
3. Click on the Protocols tab
4. Select TCP/IP Protocol and click Properties.
5. Check the DNS Host entry.

Is Oracle Net functioning properly?

If your Oracle Net configuration is correct and you are still unable to contact the Agent, the next step is to determine whether services in your Oracle Net network can be reached. You can use the TNSPING utility on each database you want to access by entering the following at the command prompt:

tnsping <network service name>

If you can connect successfully from a client to a server (or from a server to a server) using TNSPING, the command will return an estimate of the round trip time (in milliseconds) it takes to reach the Oracle Net service. This indicates Oracle Net is functioning properly.

Pinging the Intelligent Agent

If you want to see if an Agent is up, do this:

$ tnsping (address=(protocol=tcp)(host=<<hostname>>)(port=1748))

Testing the Connections to the Agent

You can also use the TNSPING utility to test connections to the Agent:

$ tnsping "(address=(protocol=tcp)(host=<<hostname>>)(port=1748))"

If there is a successful connection, you will see a message similar to the following:

Attempting to contact (address=(protocol=tcp)(host=<<hostname>>)(port=1748)) 
OK (750 msec)

If a host which is not in the invited_nodes list is trying to contact the node, the following error will be shown in the output:

Attempting to contact (address=(protocol=tcp)(host=<<hostname>>)(port=1748)) 
TNS-12547: TNS: lost contact

Did the Agent startup successfully?

To check whether the Agent process is running issue the following command:

agentctl status

If the Agent did not start up, use any of the hints listed in the following table:

Table B-1 Troubleshooting an Agent that Will Not Start

UNIX	Windows NT
Check the $ORACLE_HOME/network/log/dbsnmp*.log file for errors	Check for messages written to the NT Event Viewer (under Administrative Tools) since this is where the NT Agent writes any problems associated with startup.
Check the $ORACLE_HOME/network/log/nmiconf.log file for errors.	Check the $ORACLE_HOME/network/log/nmiconf.log file for errors.
Check that the Oracle user has write permissions to the following directory: $ORACLE_HOME/network/log	Check the properties of the Agent Service to verify the OS account used by the Agent (default is 'System') Check that the Agent user has write permissions to the following directory: $ORACLE_HOME/network/log
Check snmp_ro.ora, snmp_rw.ora, and services.ora for the entries created by the Agent. The snmp_ro and snmp_rw.ora files are located in the $ORACLE_HOME/network/admin directory, and services.ora is in the $ORACLE_HOME/network/agent directory.	Check if snmp_ro.ora, snmp_rw.ora, and services.ora are created by the Agent on startup.The snmp_ro and snmp_rw.ora files are located in the $ORACLE_HOME\network\admin directory, and services.ora is located in the $ORACLE_HOME\network\agent directory.
Compare the services listed with the services which are available on the machine. See Appendix A for valid sample files. If services are missing, check the following files for inconsistency or corruption: listener.ora tnsnames.ora oratab	Compare the services listed with the services which are available on the machine. See Appendix A for valid sample files. If services are missing, check the following files for inconsistency or corruption: listener.ora tnsnames.ora
Check if you have TCP/IP installed. TCP/IP is a requirement. See Is TCP/IP configured and running correctly?	Check if you have TCP/IP installed. TCP/IP is a requirement. See Is TCP/IP configured and running correctly?
If you still do not know why the Agent did not start, turn on tracing. (see Tracing the Intelligent Agent)	Check that you DO NOT have a systems path variable containing external drives. The Agent is a service and runs by default as SYSTEM. It also needs DLLs from the $ORACLE_HOME/bin directory. If you need external mapped drives in your path, you MUST NOT set them in the SYSTEM path. To set your own path: Move external mapped drive paths out of systems path variable and into your own. Reboot to "unset" the systems path.
	Check the $ORACLE_HOME/network/log/AGENTSRVC.log file. This file will show startup errors that occured when the Agent service was started.
If you still do not know why the Agent did not start, turn on tracing. For more information on setting up Agent tracing, see "Tracing the 9i Agent")

For both UNIX and Windows NT systems check:

$ORACLE_HOME/network/log/dbsnmp.nohup

Did the Agent connect to ALL instances on its node?

To test whether an Agent can connect to the database(s) it monitors on a given node, try connecting to each database with the following connect string:

dbsnmp/dbsnmp@address_list

You must perform this test on the node where the Agent resides.

Is the Agent running with the correct permissions? (UNIX)

To verify whether the Agent has the correct user permissions, see Installing the Intelligent Agent on page 2-2 .

Does the OS user exist and does it have the correct permissions? (Windows NT)

An OS user needs to be specified for the node and must have the following permissions:

read/write permissions to the $ORACLE_HOME/network directory and all of its sub directories
read/write permissions to the $TEMP directory ($TEMP can be found on NT by selecting Control Panel --> System). If no $TEMP is defined, the OS user must have read/write permissions to the Oracle Home directory where it creates a directory called "work".

Are there errors?

(Windows NT) Check the NT EVENT VIEWER -> APPLICATIONS -> LOG for any errors starting the DBSNMP process.

(Windows NT and UNIX) Check the $ORACLE_HOME/network/log/nmiconf.log file for discovery errors.

For both UNIX and Windows NT systems check the following file for additional errors:

$ORACLE_HOME/network/log/dbsnmp.nohup

Intelligent Agent Error Messages and Resolutions

The following error messages and resolution are categorized by operating system. Situations that apply to all systems are listed under "Generic Agent."

Generic Agent

'Failed to authenticate user' error when running a job

In order for the Agent to execute jobs on a managed node, the following conditions must be met:

An NT user account must exist that has the advanced user right, "logon as batch job." (Windows NT). The privilege can be assigned to an existing local or domain user (starting with 7.3.3), or a new NT user. Refer to Windows NT Specific Instructions in the Configuring the Intelligent Agent section.
The preferred credentials for the node must be set for that user in the Oracle Enterprise Manager Console. Refer to "Setting Preferences" in the Oracle Enterprise Manager Configuration Guide.
The user must have permissions to write to $ORACLE_HOME/network or $ORACLE_HOME\network directory.
(UNIX) Shadow password files used in high security environments must be synchronized. The Intelligent Agent looks at the local "shadow" password file for authentication information. Refer to your OS-specific documentation for more information on how to synchronize passwords on high-security systems.

'Login denied', 'Invalid username/password' messages in trace files

This usually happens if you have a databases prior to 7.3.3 on the machine. From V7.3.3 onwards, a script called CATSNMP.SQL is included in the CATALOG.SQL dictionary script. This script is responsible for creating the DBSNMP user the Agent needs to connect. Older databases did not have this script yet.

Verify if the user 'DBSNMP' exists. If not, run the catsnmp.sql script.

Important:

Do not run the 9i version of the catsnmp.sql script against pre-9i databases.

'ORACLE_HOME does not exist' when starting the Agent

This message comes from the discovery script, nmiconf.tcl. Make sure you have $ORACLE_HOME environment variable set to the ORACLE_HOME of the Agent and re-start the Agent.

The Agent is only finding one database on a certain node

If you have more than one database on a single node, then you need to make sure that each instance has a unique database name by specifying one of the following:

A unique SID.
A unique alias in the TNSNAMES.ORA file for the database.
A unique GLOBAL_DBNAME in the LISTENER.ORA file.

No snmp_ro.ora and snmp_rw.ora are generated.

This error can occur if the Agent cannot write to $ORACLE_HOME\network\admin. Refer to the $ORACLE_HOME\network\log\nmiconf.log for errors. For more information on Agent startup problems, see "Did the Agent startup successfully?".

Not all services are discovered.

Check the services.ora file to determine which services have been discovered.

All the database services the Agent finds on a machine, must be defined in the relevant SQL*Net/Oracle Net configuration files. If the service(s) are not defined, service discovery will fail and, in the worst case, the Agent will hang or return errors.

Windows NT: Beginning with version 8.0.4, the Agent searches for service names that begin with 'OracleService' or 'OracleService<SID>'. Every entry beginning with 'OracleService' is considered to be a database running on this machine. Every SID encountered by the Agent must be defined in the relevant SQL*Net/Oracle Net files.

UNIX: The oratab file is used to determine which SIDs are present. For 7.3.3 Agents and earlier, discovery fails if it encounters a SID that is not accurate (like in a Developer 2000 environment). To work around this problem, the environment variable $ORATAB can be used to access an alternate oratab file which contains only the databases you wish the Agent to see.

For the remaining databases, check the oratab file, and the SQL*Net/Oracle Net files to see if these files exist and that all definitions are present. Make sure that all of the databases are listed in the listener.ora file. For more information, see "Are the Oracle Net Configuration files correct?" and "Is Oracle Net functioning properly?" .

'Invalid service name' while registering a job or event. (Agent-specific error)

'File operation error' while registering a job or event. (OS-specific error)

These errors are usually seen when the services on the Enterprise Manager Console and the services discovered by the Agent are out of sync. For example, if you have an event registered against TESTDB and someone changes the name of the database to PRODDB, that Agent and Console are out of sync.

To fix this, start by removing all job and event registrations from this service and dropping the node where the services exist from the console. Rediscover the node from the console using the auto-discovery wizard.

NOTE: With 7.3.2 the alias are case sensitive.

If you have a NT Agent please refer to 'Invalid service name' while registering a job or event.

'Oralogin failed in orlon'

You may receive this error while executing a TCL script using the oratcl verb oralogon. "Oralogin failed in orlon" means that the connect string is either wrong or for some reason, the account used cannot logon to the database. To debug the this error, turn on Tcl tracing.

ORA-1017 'Invalid username/password'

Invalid username/password errors may occur when starting up the Agent on UNIX systems from an X-terminal. This problem can occur because the Data Gatherer (pre-9i) cannot connect to the Capacity Planner repository to upload collected data. This message will repeat every couple of minutes.

NT Agent

For any NT Operating System Error when starting the Agent

See Oracle Intelligent Agent - Windows Event Log Messages for information on Windows NT-Agent error message cross-referencing.

In order to debug the Agent after you have received an OS error, follow the following steps:

Launch the EVENT VIEWER. (This is in the ADMINISTRATIVE TOOLS icon group.) Click on LOG from the main menu, then choose APPLICATION. The source for the Agent errors are under the service name "dbsnmp". Highlight the most recent dbsnmp entry in the list. Double click on the event to get the actual results.
DBSNMP.LOG and NMICONF.LOG should contain more information about the specific error that has occurred.
Verify that snmp_ro.ora and snmp_ro.ora are in the $ORACLE_HOME\network\admin directory and they are not zero length.
Verify that user that started the Agent can read/write the queue files.
Make sure that the Machine Name and the TCP Hostname are the same.
See Verifying the TCP Name and the Computer Name on NT. Verify that SQL*Net/Oracle Net is running.
Verify that TCP/IP is configured and running correctly. (See Is TCP/IP Configured and Running?)
Remove all non-essential files from the $ORACLE_HOME/network/agent/MIB directory.
Upgrade to the latest Agent

'Failed to connect to Agent' error.

(Jobs that remain in submitted status)

There are in fact two hostname definitions on NT: One NETBios one, used for the NT's internal Named Pipes protocol, which is always installed. The other is the TCP/IP hostname, which is only configurable when you install TCP/IP on NT.

To find the NT NetBios hostname:

Start Control Panel / Network
The Computer Name in the dialog box is the NetBios hostname.

To find the TCP/IP hostname:

Start Control Panel / Network / Protocols / TCP-IP / Properties / DNS
This is the TCP/IP hostname.

On an NT server, you can 'ping' the two names, even if they are configured differently. Other clients, however, only 'ping' real TCP/IP hostnames. If the Agent is using local IPC connections, it uses Named Pipes, thus it uses the NetBios name. All external connections will use the TCP/IP name.

A mismatch in these names leads to 'unable to contact Agent', or forever pending jobs in the console. Therefore, make sure that the NetBios and the TCP/IP hostname are identical.

Receive the error failed -> 'output from job lost' while running job.

The Windows NT user that you created for the Agent (see Agent Configuration, Configuration Guide) needs read/write permissions to the $ORACLE_HOME\network\agent directory (and TEMP directory, for some applications) and read permissions to the SYSTEM32 directory

Verify that the NT user has these permissions.

UNIX Agent

Discovery fails with no services at all

First check that all of the SQL*Net/Oracle Net files are present and correctly defined. You can then debug discovery by editing your oratab file contains only a valid SID with a listener running. After you get this working, you can add the remaining entries in the oratab file to see which entry is causing the problem.

Check the $ORACLE_HOME/network/log/nmiconf.log files for errors.

NMS-0308 : 'Failed to listen on address : another Agent may be running'.

There are two possible causes for this error:

If two Agents are installed on a machine, in two different ORACLE_HOME, then you see this message if you try to start the second Agent. This is because both Agents try to listen the same default port #1748

Only have one Agent on a machine.

The port 1748 where the Agent listens is being used by someone else, or is not being released by dead process that were formerly using it (unfortunately common problem on SUN) .

To confirm port is being used by someone else

Use this command in UNIX
```
netstat -a | grep 1748 
```
If any result shown on screen that ends in "LISTENING" then the port is in use.
If the following is true :
- netstat -a | grep 1748 ---> results in "LISTENING"
- agentctl status agent ( results in "The db subagent is not started.")
- Then do this.
- ps -ef | grep dbsnmp
- kill -9 ______ (fill in process numbers)
- restart Agent with agentctl start agent

If it still fails to start the Agent, go through steps again, but before re-starting the AGENT, do this.

cd $ORACLE_HOME/network/agent
rm *.q, services.ora, snmp_ro.ora, and snmp_rw.ora
restart Agent with agentctl start agent

This will re-start the Agent and remove all of the job and event queues (.q files) it was using in the past.

If all else fails, re-booting the machine will free up the port.

NMS-001 while starting the Agent (SNMP environemnts only)

This message indicates that the SNMP Master Agent (the process on UNIX that controls the SNMP protocol) could not be contacted. By default the Agent listens and works over SQL*Net or Oracle Net, but the Agent can also work over SNMP on UNIX systems.

This message can safely be ignored unless you are trying to communicate with a Master Agent.

NMS-00207 Agent xxxx user account is locked for database yyyy

Events registered with the Agent for monitoring a 9i version of the database will not work because the database account is locked.

Under these conditions, an Enterprise Manager database up-down event will always indicate that the database is down. The Agent's log file dbsnmp.log will contain a NMS-00207 error message indicating the dbsnmp user account for the database is locked.

To resolve this problem, you must log into the database and perform the following:

Unlock the "dbsnmp" account by running the sql statement:
```
ALTER USER dbsnmp ACCOUNT UNLOCK;
```
Reset the password for dbsnmp account by running the sql statement:
```
ALTER USER dbsnmp IDENTIFIED BY <password>;
```
Add the reset password to the Agent configuration file snmp_rw.ora as follows:
```
SNMP.CONNECT.<service_name>.PASSWORD=<password>
```
where service_name is the name of the seed database as discovered by the Agent in snmp_ro.ora/snmp_rw.ora.
Stop and start the Agent using agentctl.

Run the catsnmp.sql script for that database with either the SYS or INTERNAL accounts.

NMS-205 Failure to connect to database name with username/password string

The 'dbsnmp' user could not be located.

Run the catsnmp.sql script for that database with either the SYS or INTERNAL accounts.

NMS-351 Encryption key supplied is not the one used to encrypt the file

This happens if there mismatches between the ID's in the '*.q' files in the $ORACLE_HOME/network/agent directory. This condition can be caused by the following

Hostname change on the machine.
Encryption key was overruled with a password switch, and the Agent is started without it or with another key.

Delete all the '*.q' in the $ORACLE_HOME/network/agent directory. Rebuild your repository. Restart the Agent.

Tracing the 9i Agent

Tracing and logging of the Intelligent Agent allows tracking of all communication between the Intelligent Agent and Management Server(s) as well as Agent startup and discovery information. To turn on tracing for the 9i Intelligent Agent, you will need to modify the Agent's snmp_rw.ora file. This file is normally in the $ORACLE_HOME\network\admin directory. The snmp_rw.ora is created the first time the Agent process is started. If the file is not created and you need to trace the startup process, manually create a text file and add the necessary tracing parameters to the file.

The log file, $ORACLE_HOME/network/log/dbsnmp.log, is written by the Agent on every startup, even if tracing is not turned on. It contains the name and version of the Agent and the name and location of the Agent's configuration files. If tracing is turned on, it also contains problems encountered with the database and listener connections.

The log file, $ORACLE_HOME/network/log/nmiconf.log, is created upon first start up of the Agent and appended upon subsequent Agent startups. The auto discovery is done by the Tcl script, nmiconf.tcl (hence, the log file name). This file is written to only during startup. $ORACLE_HOME/agentbin/ORATCLSH is a special-purpose TCL shell that supports all standard TCL verbs (supported in TCL82) plus a large subset (not all) of the ORATCL verbs supported by the Intelligent Agent. ORATCLSH is not a general purpose utility and may only be used in combination with the Intelligent Agent as it depends on files and data structures maintained by the Agent.

There is no documentation of ORATCLSH as it has never been part of the supported feature set of the Intelligent Agent. It is provided strictly as a debugging tool to help Oracle customers and developers in developing Enterprise Manager job and event scripts. The executable ORATCLSH is provided for debugging your TCL scripts. Before executing ORATCLSH, set the environment variable TCL_LIBRARY to point to $ORACLE_HOME/network/agent/tcl, the location of the init.tcl file.

By default the following log files are created under the Agent's ORACLE_HOME/network/log directory:

agntsrvc.log (Windows NT)
dbsnmp.log
dbsnmp.nohup (for the watchdog script dbsnmpwd)
dbsnmpj.log (job log files)
nmiconf.log (for discovery information)

Setting various tracing and logging parameters in the snmp_rw.ora file allows you to monitor the following areas:

Agent Process (dbsnmp) and Communication
Agent Job Subsystem
AGENTCTL Utility
Data Collection Services
Agent's Event Subsystem

The following tables organize the tracing and logging parameters according to their respective functional areas.

Parameters Used to Trace the Agent (dbsnmp) Process

Table B-2 Parameters Used to Trace the Agent (dbsnmp) Process

Parameter	Description
dbsnmp.trace_level = <OFF\|USER\|ADMIN\|nn>	This parameter is used to turn tracing on and specify the amount of data that is collected (trace level). A trace level of 16 provides the most detailed level of information. This parameter must be in lower case. Trace levels are identical to those used by SQL*Net or Oracle Net.
dbsnmp.trace_file= <filename>	The default trace file is dbsnmp.trc. If you want the trace to be written to a different file, add the dbsnmp.trace_file parameter.
dbsnmp.trace_directory=<directory>	sThe default trace directory is $ORACLE_HOME/network/trace. If you want to change the location of the trace file, add the dbsnmp.trace_directory parameter.
dbsnmp.trace_filecnt=<integer>	This parameter defines the maximum number of trace files to be generated.
dbsnmp.trace_filesize=<integer in kilobytes>	This parameter defines the maximum size of a trace file in kilobytes.
dbsnmp.trace_unique={true/false}	This parameter generates a unique trace file each time if set to true.
dbsnmp.trace_timestamp={true/false}	This parameter determines whether to put a timestamp before each line of trace.
dbsnmp.log_directory=<directory>	The default log directory is $ORACLE_HOME\network\log. If you want to change the name, you can add the dbsnmp.log_directory parameter. However, the Agent must have write privileges to the directory that you specify.
dbsnmp.log_file=<filename>	The default log file is called dbsnmp.log. If you want to change the name, you can add the dbsnmp.log_file parameter. This log is written by the Agent on every startup, even if tracing is not turned on. It contains the name and version of the Agent and the name and location of the Agent's configuration files. If tracing is turned on, it also contains problems encountered with the database and listener connections.
dbsnmp.log_unique={true/false}	This parameter will cause the Agent to create a unique log file each time the Agent is started.

Table B-3 Parameters Used to Trace the Job System

Parameter	Description
dbsnmpj.trace_level={OFF\|USER\|ADMIN\|nn}	This parameter is used to turn tracing on for the job system and also specifies the amount of data that is collected (trace level). A trace level of 16 provides the most detailed level of information. This parameter must be in lower case.
dbsnmpj.trace_directory=<directory>	The default trace directory is $ORACLE_HOME/network/trace. If you want to change the location of the trace file, add the dbsnmpj.trace_directory parameter.
dbsnmpj.trace_file=<filename>	The default trace file is dbsnmpj.trc. If you want the trace to be written to a different file, add the dbsnmpj.trace_file parameter.
dbsnmpj.trace_filecnt=<integer>	This parameter defines the maximum number of trace files to be generated.
dbsnmpj.trace_filesize=<integer in kilobytes>	This parameter defines the maximum size of a trace file in kilobytes.
dbsnmpj.log_directory=<directory>	The default log directory is $ORACLE_HOME\network\log. If you want to change the name, you can add the dbsnmpj.log_directory parameter. However, the Agent must have write privileges to the directory that you specify.
dbsnmpj.log_file=<filename	The default log file is called dbsnmpj.log.
dbsnmpj.log_unique={true/false}	This parameter will cause the Agent to create a unique log file each time a job is ran.

Table B-4 Parameters Used to Trace Agent Startup

Parameter	Description
agentctl.trace_level={OFF\|USER\|ADMIN\|nn}	This parameter is used to turn the tracing on for the agentctl utility (starting the agent). If a problem is occurring, Oracle Support will normally need a trace at level 16.
agentctl.trace_file=<filename>	The default trace file is agentctl.trc. If you want the trace to be written to a different file, add the agentctl.trace_file parameter.
agentctl.trace_directory=<directory>	The default trace directory is $ORACLE_HOME/network/trace. If you want to change the location of the trace file, add the agentctl.trace_directory parameter.
agentctl.trace_filecnt=<integer>	This parameter defines the maximum number of trace files to be generated.
agentctl.trace_filesize=<integer in kilobytes>	This parameter defines the maximum size of a trace file in kilobytes.
agentctl.trace_unique={true/false}	This parameter generates a unique trace file each time if set to true.
agentctl.trace_timestamp={true/false}	This parameter determines whether to put a timestamp before each line of trace.

Tracing the Data Collection Services

Because the data collection service (formerly the Data Gatherer) functionality has been integrated into the 9i Intelligent Agent, data collection-based tracing can be turned on using one of the following procedures (according to platform).

On UNIX:

Set the VP_DEBUG environment variable to one:
```
>setenv VP_DEBUG 1
```
Start the agent:
```
> agentctl start agent. 
```
Any collection activity will be logged in $ORACLE_HOME/network/log/dbsnmp.nohup.

On Windows NT (from a DOS window):

Set the VP_DEBUG environment variable to one:
```
>set VP_DEBUG=1
```

Start the Agent and redirect the output to a text file:

> dbsnmp -agent_name Oracleora920Agent > stdout.log2> odg.log

On Windows 2000 (from a DOS window):

Set the VP_DEBUG environment variable to one:
```
>set VP_DEBUG 1
```

Start the Agent and redirect the output to a text file:

> dbsnmp -agentname Oracleora920Agent > stdout.log2> odg.log

Multiple ORACLE_HOMEs

If there are multiple ORACLE_HOMEs on the same machine, perform the following.

Navigate to the specific ORACLE_HOME/bin directory of the Agent.
Set the VP_DEBUG environment variable to one: >setenv VP_DEBUG 1
```
e:/920/bin/ > set VP_DEBUG=1
```
Start the Agent
```
> agentctl start agent.
```

Tracing the Event System (tracing Tcl)

You can also turn on Event tracing by setting the dbsnmp.trace_level parameter in the snmp_rw.ora file to a level greater than or equal to one (dbsnmp.trace_level >= 1). You must shut down and re-start the Agent for these parameters to take effect. Tcl tracing creates a file, oratcl.trc, in the ORACLE_HOME/network/trace directory. Every time an event is triggered, an entry is added to the oratcl.trc file.

Interpreting Intelligent Agent Startup Errors on Windows NT/2000

When the Oracle Intelligent Agent service fails or fails to start with a pre-determined error code it calls the Windows ReportEvent function to write an entry to the event log, Windows NT then passes the parameters to the event-logging service. This in turn uses the information to write a log record to the event log. Other errors are reported to the nmi.log and nmiconf.log.

When the Windows NT event viewer application starts it uses the OpenEventLog function to open the event log for an event source. The event viewer can then use the ReadEventLog function to read event records from the log. ReadEventLog returns a buffer containing an EVENTLOGRECORD structure and additional information that describes a logged event.

Oracle Intelligent Agent - Windows Event Log Messages

When the Intelligent Agent service fails to start, the Windows Service Manager will return the underlying error code, but because it is not able to interpret the Oracle Event Message it incorrectly returns the Windows NT Win32 message text. The correct message, however, will appear in the NT event log.

The following table defines the events that the Intelligent Agent displays in the Windows NT Event viewer and the associated Win32 error text :

Table B-5 MS Windows-Intelligent Agent Error Message Translation

ID	Windows NT/2000 Message	Agent Description
1	Incorrect Function	OracleAgent failed to register its Service Control Handler
2	The system cannot find the file specified	OracleAgent failed to report its status to the Service Control Manager
3	The system cannot find the path specified	OracleAgent failed to create a thread synchronization object.
4	The system cannot open the file	OracleAgent failed to create a thread.
5	Access is denied	OracleAgent failed to allocate memory.
6	The handle is invalid	OracleAgent failed to get the encryption key.
7	The storage control blocks were destroyed	Oracle Agent failed to fun auto-discovery script nmiconf.tcl. Look in the nmiconf.log for more information. The Intelligent Agent was unable to run the Auto Discovery process. This can be either due to invalid configuration files, a problem with the TCP/IP layer, or an error in the TCL libraries. Verify the SQLNet or Oracle Net configuration files, and make sure that you can make normal loopback connections via SQLNet or Oracle Net from the server to the databases. If the problem persists, reinstall the Intelligent Agent software.
8	Not enough storage is available to process this command	OracleAgent failed to initialize Oracle CORE library
9	The storage control block address is invalid	OracleAgent failed to initialize Oracle NLS library. The NLS environment and/or registry variables are not correct. Check the system for variables beginning with 'NLS'. Try to make a connection to a database using a standard tool like SQLPlus or SQLWorksheet, to verify the NLS client settings. If the problem persists, reinstall the Required Support Files software to correct this error.
10	The environment is incorrect	OracleAgent failed to initialize Oracle SQLNet or Oracle Net library:%1. The SQLNet or Oracle Net environment and/or registry variables are not correct. Try to make SQLNet or Oracle Net connections using a standard tool, like SQLPlus or SQLPlus Worksheet. If the problem persists, reinstall the SQLNet or Oracle Net client (and server if a listener is running as well) software to correct this error.
11	An attempt was made to load a program with an incorrect format	OracleAgent failed to initialize DES encryption
12	The access code is invalid	OracleAgent failed to initialize Oracle Remote Operations Library
14	Not enough storage is available to complete this operation	OracleAgent failed to create file dbsnmp.ver
15	The system cannot find the drive specified	OracleAgent failed to create/read its queue files. The hostname of the machine is encrypted in the agent '.q' files. If this hostname found in the files by the agent does not match the name of the machine the agent is running on, this error is generated. Remove the agent '.q' files and restart the agent.
16	The directory cannot be removed	OracleAgent failed to create job scheduling symbol table
17	The system cannot move the file to a different disk drive	OracleAgent failed to initialize its connection cache. There is an incompatibility between the TCP hostname and the NetBios hostname of the machine. With the Network applet from the Control Panel, synchronize the names of the machine in the protocol properties dialogs.
18	There are no more files	OracleAgent failed to sign on to SNMP.
19	The media is write protected	OracleAgent failed to read SNMP indexes from parameter file.
20	The system cannot find the drive specified	OracleAgent failed to connect to the database. Using the information from the SQL*Net or Oracle Net configuration files, the agent was not capable of making a connection to the desired databases. Most likely a protocol error, like TCP/IP conflicts or bad TCP port being referenced in the configuration files. Check the agent log files for the specific connection errors.
21	The drive is not ready	OracleAgent failed to build SNMP cache.
22	The device does not recognize the command.	OracleAgent failed to build MIB. There are files in the $ORACLE_HOME\network\agent\mib directory which do not comply to the MIB specifications. Verify all files in that directory. Remove all non-MIB files, or corrupt MIB files.
23	Data error <cyclic redundancy check>	OracleAgent failed to register MIB row.
24	The program issued a command but the command length is incorrect	OracleAgent failed to restart its communication thread.
25	The drive issued a command but the command length is incorrect	OracleAgent failed to listen on designated port. Another OracleAgent may already be started. There was an internal error using the encryption key used in the '.Q' files. This can either be a TCP/IP conflict on the machine, or a lack of system resources on the machine preventing a proper initialization of the Intelligent Agent routines. Check the system resources, and verify if the TCP/IP setup is correct on the machine.
The following errors are generated when the Windows NT program managing the services can no longer control, or looses control over the service.
1067	The process terminated unexpectedly	Most likely a corruption in the DLL's, a problem with system settings, etc. Check for Dr. Watson logs, errors in the event viewer and messages in the log files to get more details on the exact condition.
2140	An internal Windows NT error occurred	The services program received conflicting information from the service. Most likely, an abnormal termination of the Intelligent Agent, due to conflicting system information discovered. More information about the abort of the Intelligent Agent can be found in the discovery log files.
2186	The service is not responding to the control function	The Intelligent Agent failed to report it's status to the SERVICES program monitoring the services. If you can not stop the Agent service, use the 'KILL' command from the command line to stop the agent process. The 'KILL' command is part of the optional MS Resource Kit, and not a standard NT tool.

Typical Intelligent Agent Configuration Issues on UNIX

The Intelligent Agent software is delivered with the RDBMS server software. However, this does not mean that the Intelligent Agent software must be installed together with the database. It is quite possible to install the Agent alone, in a dedicated "$ORACLE_HOME", separate from the rest of the Oracle software.

The only thing the Intelligent Agent needs is SQL*Net or Oracle Net, to make connections to the databases it needs to monitor, and to be able to communicate with the rest of the Enterprise Manager framework. The SQL*Net or Oracle Net product, and the underlying 'Common Libraries' are products that are installed automatically whenever the Agent is installed on UNIX.

It is not necessary to have a SQL*Net listener running in the same "$ORACLE_HOME" as the Agent, and it also does not have to be of the same base version as the Agent.

Linking the Intelligent Agent

Important:

Be sure to shut down the Agent BEFORE relinking the software.

As soon as the software is installed from the installation media, the Intelligent Agent is relinked using the current system libraries present on the system.

If a change is made to the UNIX kernel, or the system libraries, it is advised to relink the Intelligent Agent, using the following commands:

$ cd $ORACLE_HOME/network/lib
$ make -f ins_oemagent.mk install

This will create two new executables: dbsnmp and oratclsh, both created in the "$ORACLE_HOME/bin" directory. If a version of these executables already exists, the old ones will be renamed to "dbsnmp0" and "oratclsh0". As soon as the new software has been tested, these safety copies can be removed.

When relinking database software, or after making changes to the installed SQL*net protocols drivers, this does require a shutdown of all databases of that version!

As soon as the agent is relinked however, either the "root.sh" file needs to be executed again, or a manual intervention is needed to adjust the dbsnmp executable.

If the "root.sh" file is meanwhile adjusted or overwritten by a newer file, the following commands have to be executed manually, as the 'root' user:

$ cd $ORACLE_HOME/bin
$ chmod 6751 dbsnmp 
$ chown root dbsnmp

These steps are essential for the proper working of the agent. If the agent has not the 'setuid' permissions (given by the chmod '6751' command), or is not owned by root ('chown root' command), the discovery can fail, and jobs will not get executed properly.

Also, when the agent has already been started on the machine, some of the files do have the 'root' ownership, making the agent fail to start, and update the wrong files, after a relink and an ownership back to the Oracle owner.

Running the Intelligent Agent

Whenever a program runs on UNIX under the 'root' permissions, the environment variable "LD_LIBRARY_PATH" is not read for security reasons. This means that all shared libraries, linked dynamically to the .EXE will have to be referenced using their absolute location on the disk.

You can check the linked shared libraries using the 'LDD' command. For example:

$ ldd dbsnmp

To avoid problems with the shared libraries, there are three options:

Link the software statically.

If the libraries are statically linked in, the 'ld' will not consider them 'shared', solving the problem. Downside here is that the executable will be a lot larger in size.
Copy or link the shared libraries in the "/usr/lib" directory.

An easy and straightforward trick is to create a symbolic link to the needed shared library in "/usr/lib". Since this directory is hardcoded into the library loader, all shared objects placed in this directory will always be found.

Potential problems can arise in this case if several versions of software are installed on the same machine. Since the "/usr/lib" directory is the same for the entire machine, any file copied or linked in this directory will be used throughout the machine, meaning that other versions of software might be picking up the wrong shared object.
Reference the shared objects by their absolute path.

The best solution, but also the hardest, as it includes modifying the make file and adding the full hardcoded path to the used libraries. After the modification, relink the software, to make sure the libraries are found correctly.

Specifically for the Agent, the following errors can be encountered if there is a problem with the shared libraries:
```
ld: Can not map libclntsh.so.1.0
ld: Error opening libclntsh.so.1.0
ld: Can not find libnet.so
```

If an error is generated when the agent starts, perform the following:

Relink the agent:
```
$ make -f ins_oemagent.mk install
```
Change the owner and permissions of the executable:
```
$ chmod 6751 dbsnmp
$ chown root dbsnmp
```

Understanding and Troubleshooting the Data Gatherer

Important:

This section only applies pre-9i Intelligent Agents. The data collection services provided by the Data Gatherer are now integrated with the 9.x Intelligent Agent.

The Oracle Data Gatherer is a daemon process which manages the collection of performance statistics from the Oracle database and from the host operating system for use by Enterprise Manager tools, such as the Oracle Performance Manager and the Oracle Capacity Planner. As mentioned above, this functionality is now an integral part of 9.x Agent. This section only applies to older versions of the Agent/Data Gatherer.

Data Gatherer Configuration

The Data Gatherer collects the following types of data:

Operating System
Database
Oracle Application's Concurrent Managers
Oracle HTTP Server
Microsoft SQL*Server

You may not be able to collect operating system data if the Data Gatherer is not available for that particular operating system. To collect operating system data the Data Gatherer must be installed on the same host as the OS. It may not be possible to install and configure the Oracle Data Gatherer on a particular host if both of the following requirements are not met:

The host operating system must support the installation and configuration of the Oracle Data Gatherer. Base development is done for the Data Gatherer on NT and Solaris
An Oracle Home for Oracle 8.0.4 or later must exist on the host.

Using the Data Gatherer when Installed on Server Host

This is the assumed configuration for using the Oracle Data Gatherer. The Data Gatherer is installed separately as part of the database server installation. In 8.0.5 or higher, the Data Gatherer is installed along with the Intelligent Agent (but not an integral part of the Agent, as is the case for 9.x versions of the Agent). The Data Gatherer can be used to monitor database statistics for any database on that host, and also can be used to monitor OS statistics for the host itself.

Using the Data Gatherer when Installed on Client Host

It is possible to install the Data Gatherer on the same host where the client will be run from (if the client is Windows NT 4.0, this is not supported on Windows 95 or Windows 98). In this configuration, you will be able to monitor the database statistics for remote databases, but will not be able to monitor the operating system statistics on the remote host.

Using the Data Gatherer on an Alternative Port

The Data Gatherer and clients are installed and run assuming the use of a well-known (IANA registered) port (1808), which is used for communication between clients and the Data Gatherer server. If you wish to use an alternate port, you may do so, however this configuration is not supported.

Using Multiple Oracle Homes

It is possible to install the Oracle Data Gatherer in an environment with multiple Oracle homes, however there are two issues to keep in mind if you attempt to do this:

Because the Data Gatherer uses a well known port, if you intend to run the Data Gatherer in two homes simultaneously you will need to run one on an alternate port (which is not supported)
Database connect strings delivered to the Data Gatherer must be resolvable from the SQL*Net environment in that Oracle home.

Data Gatherer Recovery Capabilities

Data Gatherer Restart at Host Restart

The Data Gatherer is configured to save the state of all current historical collections, such that when it restarts it will create recovery threads to restart these collections from the state files. If the Data Gatherer is configured to start automatically when the system reboots, then collections should be able to continue.

Collecting Historical Data from a Cycling Database

If the database from which data is being collected is cycled (e.g. shutdown each evening for backups) then the Data Gatherer is designed to continue collecting data from the database when it restarts. The Data Gatherer attempts to reconnect to the database at the specified collection interval until it becomes available.

Miscellaneous Data Gatherer Issues

The Data Gatherer alert log ($ORACLE_HOME\odg\log\alert_dg.log) contains many messages of interest that the Data Gatherer wishes to save. This currently includes errors reported by the Data Gatherer and informational messages. All messages included in the alert log include a timestamp.
Starting the Data Gatherer:

UNIX: vppcntl -start (UNIX command).

NT: From the Control Panel Services applet start the OracleDataGatherer service.
Stopping the Data Gatherer:

UNIX: vppcntl -stop(UNIX command).

NT: From the Control Panel Services applet stop the OracleDataGatherer service.
Checking the Data Gatherer status:

vppcntl - status

This status check will result in one of two messages:

The Oracle Data Gatherer is running!

-OR-

The Oracle Data Gatherer is not running

Clean Starting the Intelligent Agent

Clean starting the Agent involves clearing all existing job and event definitions. This should only be necessary when the Enterprise Manager environment needs to be reinitialized, or upon specific request from Customer Support. Actions will need to be performed from both the Console and the Agent node.

To clean start the Agent:

From the Enterprise Manager Console.
- Remove all jobs and events registered against the machine the agent is running on.
- As soon as all events and jobs have been removed, shut down the Console.
Stop the Intelligent Agent currently running on the desired target.

On UNIX, issue the following command:
```
$ agentctl stop agent
```
After the stop command has been issued, use the 'ps' command to verify that the 'dbsnmp' processes have been stopped. If the Intelligent Agent cannot be stopped, use the 'ps' command to obtain the process ID's of the dbsnmp processes, and use the 'kill -9' command to terminate these processes.

On Windows NT, use the Control Panel / Services applet to turn the Agent service off, or issue the command line option:
```
C:\> agentctl stop agent 
```
When the agent is stopped, use the TaskManager to verify that the 'dbsnmp' process has been stopped.
Go to the "$ORACLE_HOME/network/agent" directory and delete the following files:
- SERVICES.ORA: File containing all the services the agent has discovered. This file will be recreated the next time the agent starts.
- All files with the '.q' extension: These files are the binary representation of all registered and running jobs and events. The agent creates new 'q' files on startup when they do not exist.
Information about the host on which the agent is running is also stored in these files. If the name or the IP address of the agent machine changes, these files need to be recreated.
- All files with the '.inp' extension: These are the parameter files for registered jobs.
- All files with the '.jou': These are journal files with information the agent will use to execute jobs.
- All files with the 'out' prefix: These are temporary output files that are generated when jobs are being executed. These files should never remain in this directory after a job finishes.
- All files with the 'tcl' prefix: These are Tcl template scripts, including the specific commands, specified in the job sent to the agent
- DBSNMP.VER : This is a text file with the agent version information. This file will also be recreated when the agent starts again.
Go to the "$ORACLE_HOME/network/admin" directory. In this directory, remove the following files:
- SNMP_RO.ORA : The read-only information the agent has discovered of the services on the machine.
  
  This file should never be edited by a user. During startup, this file is read if it exists, and then recreated again with the new discovery information.
- SNMP_RW.ORA : The read-write information the agent has discovered of the services on the machine.
  
  Some of the information in this file can be edited by an administrator to provide more info about the discovered services.
  
  Upon Agent startup, this file is read if it exists, and after the discovery written again. Information is only added to this file.
Rename or remove the existing log files the agent has already created. This allows you to track any log messages since clean starting the Agent.

The following files, located in the "$ORACLE_HOME/network/log" directory. They are used during startup of the agent:
- NMICONF.LOG : Discovery log files
- NMI.LOG : SQL*Net connection errors (Windows NT only)
- DBSNMP.LOG : Communication and working thread logging, if logging is enabled
You should also remove all files from $ORACLE_HOME/network/agent/library directory.
Create an empty SNMP_RO.ORA file and add the following line.
```
snmp.visibleservices = ()
```
If tracing is needed to debug a certain situation, a new "SNMP_RW.ORA" can be created, with the debug parameters:
```
dbsnmp.trace_level=16
dbsnmp.trace_unique=true
```

Restart the Agent.

After the agent has started, verify the "SERVICES.ORA" file first. If this file contains all the services on the machine, then check the "SNMP_RO.ORA" and "SNMP_RW.ORA" files. Discovery problems can be found in the file "NMICONF.LOG".

Important!:

Deleting the '.q' files erases all state information from the Agent, i.e., the Intelligent Agent has no information about the registered jobs and events.

Removing the '.q' files while jobs and events are submitted against the agent will result in synchronization errors between the framework and the agent. Therefore, use this method only on specific request by Customer Support when there is an explicit need for re-initializing the Intelligent Agent.

Events/jobs are internally identified by a sequence number. When a 'q' file is created, the sequence is reset. The Management Server on submission of an event realizes that the internal ID that it gets back is less than any other that it has previously registered for the node and triggers the message indicating there is a skew between the systems. The only option is to remove all the events and jobs and reregister them. As soon as the Management Server detects a mismatch of ID's, the Agent will be marked as 'corrupted', and all job or events you wish to send to this agent will fail with the error:

VNI-4040: The agent on node is not in sync with the Management 
Server

Delete the contents of the $ORACLE_HOME/network/agent/reco directory.

Diagnosing Intelligent Agent Discovery Errors on UNIX

The discovery process on UNIX involves the following actions:

Retrieve the primary host name and its aliases
Read the ORATAB file. From this file, the list of databases, and the corresponding ORACLE_HOMEs are retrieved.
Read the SQL*Net LISTENER.ORA and SQLNET.ORA files for each ORACLE_HOME read from the ORATAB file. The names of the database services are determined form the LISTENER.ORA file. These names are the names visible in the Enterprise Manager Console, and these names are used as TNS aliases to connect to the database.
If a GLOBAL_DBNAME parameter for a database is not specified in the LISTENER.ORA file, the TNSNAMES.ORA file is scanned in search for an applicable TNS alias.
If a TNS alias is not found, or if there is a duplicate TNS alias string, the Intelligent Agent generates a TNS alias for the database, and uses this generated name as the name for the service.

Files Used During Discovery on UNIX

listener.ora : Definitions of incoming SQL*Net connections

1 file per $ORACLE_HOME

Located in one of the following locations (using this order searching for it):

$TNS_ADMIN
/etc or /var/opt/oracle
$ORACLE_HOME/network/admin

nmiconf.log : Intelligent Agent discovery warnings/errors

1 per Intelligent Agent

Located in $ORACLE_HOME/network/log

nmiconf.lst : List of third party additional discovery script to run

1 per Intelligent Agent

Located in $ORACLE_HOME/network/agent/config

nmiconf.tcl : Intelligent Agent discovery script

1 per Intelligent Agent

Located in $ORACLE_HOME/network/agent/config

oratab : File with all databases present on the machine

Only 1 per machine

Located in either /etc or /var/opt/oracle

services.ora : File with all service definitions the agent found

1 per Intelligent Agent

Located in $ORACLE_HOME/network/agent

snmp_ro.ora : File with all read-only service information

1 per Intelligent Agent

Located in $TNS_ADMIN or $ORACLE_HOME/network/admin

snmp_rw.ora : File with all updateable service information

1 per Intelligent Agent

Located in $TNS_ADMIN or $ORACLE_HOME/network/admin

sqlnet.ora : File with SQL*Net specific parameters

1 file per $ORACLE_HOME

Located in either (using this order searching for it):

$TNS_ADMIN
/etc or /var/opt/oracle
$ORACLE_HOME/network/admin

tnsnames.ora : File with the TNS aliases to connect to databases

1 file per $ORACLE_HOME

Located in either (using this order searching for it):

$TNS_ADMIN
/etc or /var/opt/oracle
$ORACLE_HOME/network/admin

Diagnosing the Discovery Problem on UNIX

Phase 1: Checking the ORATAB file

The ORATAB file is located in either the /etc, or the /var/opt/oracle directory.

You should consult your OS-specific documentation to see which directory is used to store the configuration files.

Things to look at:

Dummy databases can be specified with a SID specified as '*'.
The specification of the SID is case sensitive. This means that in order to have a valid service, the SID needs to specified in the exact same case in ALL configuration files.
If you do not want certain database(s) to be visible in Enterprise Manager, you can prevent databases from being discovered by using the ORATAB file:
1. Copy the ORATAB file to another location. The physical location of the file is not important, as long as the Intelligent Agent is capable of reading the file on startup.
2. Edit the copied file, and remove the database entries that you do not want discovered.
3. Set an environment variable. Example (using Csh):
```
ORATAB=$ORACLE_HOME/network/agent/oratab; export ORATAB
```
4. Restart the Intelligent Agent.
The result of the ORATAB parsing is two lists:
- A list with potential database services.
- A list of ORACLE_HOMEs present on the machine.

Phase 2: Checking the SQLNET.ORA file

For every ORACLE_HOME on the system, the Agent looks for the SQL*Net or Oracle Net files. It needs the SQLNET.ORA and LISTENER.ORA files first, to obtain the database service definitions. Sometimes, in the case of missing information, the TNSNAMES.ORA file is also required.

The Agent searches for the SQL*Net files in the follow order:

First, it checks the environment in search for a TNS_ADMIN variable. If one is found, this directory is used for the retrieval of the SQLNET information.

Note:

The Intelligent Agent uses its own environment. It does not perform a login (running the profile/login scripts), nor does it run the 'oraenv' script to get the information for a specific ORACLE_HOME. If certain TNS_ADMIN values are enforced in login scripts, or in the 'oraenv' script which are different from the one in the Agent environment, they are not used by the Intelligent Agent!

If you have more than one ORACLE_HOME on the system, and a TNS_ADMIN variable is specified, 'duplicate definition' warnings will be logged in the NMICONF.LOG file starting from the second ORACLE_HOME. This occurs because the Agent finds the same SQL*Net files for that home, which will naturally contains identical information. These warnings can be ignored.

If a TNS_ADMIN environment variable is not specified, the default OS specific configuration location is searched for SQL*Net files. This can either be the '/etc' directory or '/var/opt/oracle', depending on the UNIX flavor you are working on.

Note:
If the Agent finds files in the OS specific location, and there are several ORACLE_HOMEs on the system, 'duplicate definition' warnings will be logged in the NMICONF.LOG file.

Finally, if nothing is found, the default $ORACLE_HOME/network/admin directory is searched for the necessary files.

Note:

If SQL*Net files are not found in a particular $ORACLE_HOME, the Agent skips to the next home and searches for the info there. If after completion the scan of all homes, information about a specific SID found in the ORATAB file is not found, a warning will be logged in the NMICONF.LOG file saying the SID will be skipped. This is a common warning when the Intelligent Agent is installed in a separate ORACLE_HOME: During the installation of the Agent, the install routines will adjust the ORATAB file, but there is no actual database with the SID name given during the installation.

Once the SQL*Net configuration directory is established, the actual reading of the information can begin.

Only one parameter is read from the SQLNET.ORA file: The names.default_domain parameter.

Phase 3: Checking the LISTENER.ORA file.

Using the same SQL*Net configuration directory, the information from the listener.ora file is read.

This contains two parts:

List of how a service can be contacted using this listener. The protocol definitions, as specified in the listener definition itself. TCP protocol definition is used by the Agent to define the way it can connect to this database. It is also used in cases where the Agent needs to scan the TNSNAMES.ORA files to verify which TNS entry matches which listener definition for a database.

Note 1:

If the protocol descriptions contains a lot of IPC entries and other non-TCP definitions, the length of the protocol definition can grow quite large.

If the length of the protocol definitions, added with the SID description part for a database surpasses the SQL*Net limit of 256 characters, the error ORA-12163 is generated when a connection is made using the TNS string the Agent constructed.

ORA-12163 TNS: Connect descriptor is too long.

The workaround here is to remove some of the non-TCP entries from the listener definition and restart the Agent.

Note 2:

If the hostname defined in variable HOST of TCP definition does not match the hostname discovered by the Intelligent Agent, a message will be logged in NMICONF.LOG:

Could not find corresponding listener ...

Then SID listened by this listener will be skipped and if no other listener listens to them, the following messages are logged in listener.ora :

No listener found for SID ...

The list of all databases this listener is working for. Every SID encountered in the SID description part of the LISTENER.ORA file is verified:
- The 'extproc' SID description is skipped automatically.
- If the SID was not present in the ORATAB file it is skipped.
- If the SID is already encountered in another LISTENER.ORA file on the system it is skipped.
  
  A message is logged in the NMICONF.LOG.
  
  Example:
```
Warning : Multiple Listeners found for SID ORCL.
```

For all remaining SIDs found, a service name is generated. This service name is unique on the machine. In case no service name is enforced in the LISTENER.ORA file with the GLOBAL_DBNAME parameter, the TNSNAMES.ORA file is searched for a valid service name.

If there are duplicates service names encountered, the Agent constructs a new unique service name for this database. A message appears in the NMICONF.LOG warning about the newly constructed name.

Note:

When different machines are using the same service names, the discovery from the Enterprise Manager navigator fails, and the duplicate service names is added to the list of managed services in Enterprise Manager.

The end result is a list of listeners. And for each listener the list of SIDs the listener works for. Every SID in these lists on its turn has, a list of the details needed for that database service.

Phase 4: Verifying the Information

As soon as all the files are parsed and treated, and all services are found, the Agent verifies if all the information is present and valid.

If there is a listener does not have any SID, a warning is placed in the NMICONF.LOG saying the listener is skipped.

Example:

Warning : Listener LISTENER defined in

/oracle/815/network/admin/listener.ora will be ignored.

If there is a database found in the ORATAB, which does not have a listener working for it, the SID will not be 'discovered'.

A message appears in the NMICONF.LOG saying the SID will be skipped.

Example:

Warning : No Listener found for SID ORCL. ORCL will be skipped

All remaining information is considered 'discovered' and is placed in the discovery files SNMP_RO.ORA, SNMP_RW.ORA and SERVICES.ORA.

Important:

The SERVICES.ORA and SNMP_RO.ORA file are ALWAYS completely rewritten. The SNMP_RW.ORA file is, however, only updated with the information about the new services. If is therefore quite possible to have gaps in the indexes, or to find information about services in this file which are no longer present on the machine.

Diagnosing Agent Discovery Errors on Windows NT

The discovery process on Windows NT involves the following actions:

Get the primary host name and its aliases
Get a list of the Oracle services from the registry. Databases with their the corresponding ORACLE_HOMEs are retrieved from this list.
For each ORACLE_HOME encountered, the SQL*Net files LISTENER.ORA and SQLNET.ORA are read. From the LISTENER.ORA file, the names of the database services are determined. These names are the names visible from the Enterprise Manager Console. These names are also used as TNS aliases to connect to the database.
If there is no GLOBAL_DBNAME parameter specified in the LISTENER.ORA file for a database, the TNSNAMES.ORA file is scanned in search for an applicable TNS alias.
If no TNS alias is found, or in case of duplicate TNS alias string, the Intelligent Agent generates a TNS alias for the database, and will use this generated name as the name for the service.

Files Used During Discovery

listener.ora : File with definitions of incoming SQL*Net connections

1 file per $ORACLE_HOME

Located in either (using this order searching for it):

$TNS_ADMIN in the environment
$TNS_ADMIN in the registry
$ORACLE_HOME\network\admin

nmiconf.log : File with Intelligent Agent discovery warnings/errors

1 per Intelligent Agent

Located in:

$ORACLE_HOME\network\log

nmiconf.lst : List of 3rd party additional discovery script to run

1 per Intelligent Agent

Located in:

$ORACLE_HOME\net80\agent\config (Version 8.0.X only)
$ORACLE_HOME\network\agent\config

nmiconf.tcl : Intelligent Agent discovery script

1 per Intelligent Agent

Located in:

$ORACLE_HOME\net80\agent\config (Version 8.0.X only)
$ORACLE_HOME\network\agent\config

services.ora : File with all service definitions the agent found

1 per Intelligent Agent

Located in:

$ORACLE_HOME\net80\agent (Version 8.0.X only)
$ORACLE_HOME\network\agent

snmp_ro.ora : File with all read-only service information

1 per Intelligent Agent

Located in either (in order according to search priority):

$TNS_ADMIN in the environment
$TNS_ADMIN in the registry
$ORACLE_HOME\net80\admin (Version 8.0.X only)
$ORACLE_HOME\network\admin

snmp_rw.ora : File with all updateable service information

1 per Intelligent Agent

Located in either (in order according to search priority):

$TNS_ADMIN in the environment
$TNS_ADMIN in the registry
$ORACLE_HOME\net80\admin (Version 8.0.X only)
$ORACLE_HOME\network\admin

sqlnet.ora : File with SQL*Net specific parameters

1 file per $ORACLE_HOME

Located in either:

$TNS_ADMIN in the environment
$TNS_ADMIN in the registry
$ORACLE_HOME\net80\admin (Version 8.0.X only)
$ORACLE_HOME\network\admin

tnsnames.ora : File with the TNS aliases to connect to databases

1 file per $ORACLE_HOME

Located in either (ordered according to search priority):

$TNS_ADMIN in the environment
$TNS_ADMIN in the registry
$ORACLE_HOME\net80\admin (Version 8.0.X only)
$ORACLE_HOME\network\admin

Diagnosing the Discovery Problem on NT

Phase 1: Scanning the registry

The registry is scanned for database services. For each 'OracleService' NT service found, a potential database service entry is created, and the corresponding ORACLE_HOME is determined.

Things to point here:

The specification of the SID is case insensitive.
You cannot prevent discovery of the databases here, like with the ORATAB

on UNIX.

Scanning the registry generates two lists:

A list with potential database services.
A list of ORACLE_HOME's present on the machine.

Phase 2: Scanning the SQLNET.ORA file

For every ORACLE_HOME on the system, the Agent looks for the SQL*Net/Oracle Net files. It needs the SQLNET.ORA and LISTENER.ORA files first, to get the database service definitions. Sometimes, in case of missing information, the TNSNAMES.ORA file is also required.

The Agent looks for the SQL*Net files in this order:

It checks the environment in search for a TNS_ADMIN variable. If one is found, this directory is used for the retrieval of the SQL*Net/Oracle Net information.
Next, the registry is checked in search for a TNS_ADMIN variable in the 'HOMEx' of the ORACLE_HOME the Agent is verifying. If one is found there, it is used.

Finally, if nothing is found, the default $ORACLE_HOME\net80\admin (Versions 8.0.X only) or $ORACLE_HOME\network\admin directory is searched for the necessary files.

Note:

If no SQL*Net/Oracle Net files are found in a particular $ORACLE_HOME, the Agent skips to the next home and searches for the info there. If after all Oracle_homes are scanned and information about a specific SID found in the registry is not found, a warning is logged in the NMICONF.LOG file saying the SID will be skipped.

Once the SQL*Net/Oracle Net configuration directory is established, the actual reading of the information can begin.

Only one parameter is read from the SQLNET.ORA file: The names.default_domain parameter.

Phase 3: Looking at LISTENER.ORA file

Using the same SQL*Net/Oracle Net configuration directory, the information from the listener.ora file is read.

This contains two parts:

List of how a service can be contacted using this listener. This list consists of protocol definitions as specified in the listener definition itself. TCP protocol definition will be used by the Agent to define the way it can contact this database. It will also be used in case the Agent needs to scan the TNSNAMES.ORA files to verify which TNS entry matches which listener definition for a database.

Note:

If the protocol descriptions contains a lot of IPC entries and other non-TCP definitions, the length of the protocol definition can grow quite large. If the length of the protocol definitions, added with the SID description part for a database surpasses the SQL*Net/Oracle Net limit of 256 characters, the error ORA-12163 will be generated when a connection is made using the TNS string the Agent constructed.

ORA-12163 TNS:Connect descriptor is too long

The workaround here is to remove some of the non-TCP entries from the listener definition and restart the Agent.

Note:

If the hostname defined in variable HOST of TCP definition does not match the hostname discovered by the Intelligent Agent, a message will be logged in NMICONF.LOG :

Could not find corresponding listener ...

Then SID listened by this listener will be skipped and if no other listener listens to them following messages will be logged in listener.ora :

No listener found for SID ...

The list of all databases this listener is working for. Every SID encountered in the SID description part of the LISTENER.ORA file will be verified:
- The 'extproc' SID description is skipped automatically
- If the SID was not present in the registry file it is skipped
- If the SID is already encountered in another LISTENER.ORA file on the system it is skipped. A message will be logged in the NMICONF.LOG.
Example:
```
Warning : Multiple Listeners found for SID ORCL.
```

For all remaining SID's found a service name will be generated. This service name will be unique on the machine. In case no service name is enforced in the LISTENER.ORA file with the GLOBAL_DBNAME parameter, the TNSNAMES.ORA file will be searched for a valid service name.

If there are duplicates service names encountered, the Agent will construct a new unique service name for this database. A message will appear in the NMICONF.LOG warning about the newly constructed name.

The end result here is a list of listeners, with for each listener the list of SID's this listener is working for. Every SID in those lists on its turn has a list of the details needed for that database service.

Phase 4: Verifying the information

As soon as all the files are parsed and processed, and all services are found, the Agent verifies that all the information is present and valid.

If there is a listener with no SIDs, a warning is placed in the NMICONF.LOG saying the listener will be skipped.

Example:
```
Warning : Listener LISTENER defined in C:\ORA920\network\admin\listener.ora 
will be ignored
```

If a database has no listener servicing it, the SID will not be 'discovered'. A message will appear in the NMICONF.LOG saying the SID will be skipped.

Example:
```
Warning : No Listener found for SID ORCL. ORCL will be skipped
```
At startup the Agent tries to connect to each discovered database. Therefore each open database should have two dbsnmp sessions once the Agent is started :

Select username from v$session where username = 'DBSNMP'

If no data retrieved and the Agent is running, check that the user DBSNMP exists and connects ok.

All remaining information is considered 'discovered' and is placed in the discovery files SNMP_RO.ORA, SNMP_RW.ORA and SERVICES.ORA.

Important:

The SERVICES.ORA and SNMP_RO.ORA file are ALWAYS rewritten completely.

The SNMP_RW.ORA file is however only updated with the information about the new services. If is therefore quite possible to have gaps in the indexes, or to find information about services in this file which are no longer present on the machine.

B Troubleshooting

Troubleshooting the Intelligent Agent

Quick Checks

Quick Checks for the Windows NT Agent

Quick Checks for UNIX Agents

Additional Checks

Is TCP/IP configured and running correctly?

Correcting TCP/IP configuration problems

Do the DNS Name and the Computer Name Match? (Windows NT)

Are the Oracle Net Configuration files correct?

(UNIX)

(Windows NT)

Is Oracle Net functioning properly?

Pinging the Intelligent Agent

Testing the Connections to the Agent

Did the Agent startup successfully?

Table B-1 Troubleshooting an Agent that Will Not Start

Did the Agent connect to ALL instances on its node?

Is the Agent running with the correct permissions? (UNIX)

Does the OS user exist and does it have the correct permissions? (Windows NT)

Are there errors?

Intelligent Agent Error Messages and Resolutions

Generic Agent

'Failed to authenticate user' error when running a job

'Login denied', 'Invalid username/password' messages in trace files

'ORACLE_HOME does not exist' when starting the Agent

The Agent is only finding one database on a certain node

No snmp_ro.ora and snmp_rw.ora are generated.

Not all services are discovered.

'Invalid service name' while registering a job or event. (Agent-specific error)

'File operation error' while registering a job or event. (OS-specific error)

'Oralogin failed in orlon'

ORA-1017 'Invalid username/password'

NT Agent

For any NT Operating System Error when starting the Agent

In order to debug the Agent after you have received an OS error, follow the following steps:

'Failed to connect to Agent' error.

(Jobs that remain in submitted status)

Receive the error failed -> 'output from job lost' while running job.

UNIX Agent

Discovery fails with no services at all

NMS-0308 : 'Failed to listen on address : another Agent may be running'.

NMS-001 while starting the Agent (SNMP environemnts only)

NMS-00207 Agent xxxx user account is locked for database yyyy

NMS-205 Failure to connect to database name with username/password string

NMS-351 Encryption key supplied is not the one used to encrypt the file

Tracing the 9i Agent

Parameters Used to Trace the Agent (dbsnmp) Process

Table B-2 Parameters Used to Trace the Agent (dbsnmp) Process

Table B-3 Parameters Used to Trace the Job System

Table B-4 Parameters Used to Trace Agent Startup

Tracing the Data Collection Services

On UNIX:

On Windows NT (from a DOS window):

On Windows 2000 (from a DOS window):

Multiple ORACLE_HOMEs

Tracing the Event System (tracing Tcl)

Interpreting Intelligent Agent Startup Errors on Windows NT/2000

Oracle Intelligent Agent - Windows Event Log Messages

Table B-5 MS Windows-Intelligent Agent Error Message Translation

Typical Intelligent Agent Configuration Issues on UNIX

Linking the Intelligent Agent

Running the Intelligent Agent

Understanding and Troubleshooting the Data Gatherer

Data Gatherer Configuration

Using the Data Gatherer when Installed on Server Host

Using the Data Gatherer when Installed on Client Host

Using the Data Gatherer on an Alternative Port

Using Multiple Oracle Homes

Data Gatherer Recovery Capabilities

Miscellaneous Data Gatherer Issues

Clean Starting the Intelligent Agent

Diagnosing Intelligent Agent Discovery Errors on UNIX

Files Used During Discovery on UNIX

Diagnosing the Discovery Problem on UNIX

Phase 1: Checking the ORATAB file

Phase 2: Checking the SQLNET.ORA file

Phase 3: Checking the LISTENER.ORA file.

Phase 4: Verifying the Information

Diagnosing Agent Discovery Errors on Windows NT

B
Troubleshooting