1
Intelligent Agent Overview

This chapter provides a brief overview of the Intelligent Agent. The following topics are covered:

Oracle Intelligent Agent: An Overview

The Oracle Intelligent Agent is an autonomous process running on a remote node in the network. An agent resides on the same node as the service it supports. However, the agent can support more than one service on a particular node. For example, if two databases are installed on one machine, a single agent can support both databases. The agent is responsible for:

Providing local services or calling operating system dependent services to interact locally with the managed targets.
Accepting jobs or events from the Oracle Enterprise Manager Console or other third-party applications.
Running Oracle Enterprise Manager jobs, collecting their results and output, and/or queuing the jobs as required.
Checking for events, and queueing the resulting event reports for Oracle Enterprise Manager.
Canceling jobs or events as directed by the Console or other applications.
Handling Simple Network Management Protocol (SNMP) requests, if SNMP is supported on the agent's platform.

For information on configuring the agent, see the Oracle server platform-specific installation documentation for your system.

Note:
Enterprise Manger version 1 does not use version 2's middle-tier Management Server. Because this manual is geared towards users of both version 1 and version 2, users of Enterprise Manager version 1 should ignore references to the Management Server.

Characteristics

Intelligent Agents are autonomous because they function without requiring that the Console or Management Server be running. An agent that services a database can run when the database is down, allowing the agent to start up or shut down the database. The Intelligent Agents can independently perform administrative job tasks at any time, without active participation by the administrator. Similarly, the agents can autonomously detect and react to events, allowing them to monitor the system and execute a fixit job to correct problems without the intervention of the administrator.

The agents operate independently of the Console and are able to execute jobs and monitor events when the administrator has logged out of the Console. The agents queue any job or event messages destined for that administrator, and deliver them when the administrator logs in to a Console again. Information about the state of jobs and events are stored in files on the agent's node. These files have a ".q" extension and are stored in the $ORACLE_HOME/network/agent directory.

Note:
If the number of job or event notifications queued for delivery to the Management Server exceeds 500 messages, all notifications will be deleted from the queues.

Job and Event Support

Jobs and events are implemented as Tcl scripts. When the agent executes a job or tests for an event, it runs the appropriate Tcl script.

When the Management Server sends a message to an agent on behalf of an administrator logged into the Console, it also sends the information about the administrator's language and character set environment. The agent uses the NLS environment information when it performs database administration tasks on behalf of the administrator. This allows administrators to manage databases in their native languages. For example, an administrator in France can administer a database in Germany and receive messages in French.

Simple Network Management Protocol Support

The agent supports Simple Network Management Protocol (SNMP), allowing third-party systems management frameworks to use SNMP to receive SNMP traps directly from the agent. The agent provides access to Oracle's database Management Information Base (MIB) variables. You can submit jobs or events that access Oracle MIB variables even when the database resides on a platform that does not support SNMP. For more information on SNMP, see the Oracle SNMP Support Reference Guide.

Service Discovery Process

When you start the Agent, the first operation it must perform is to discover what services exist on the node that it monitors. The following "discovery" algorithms document the service discovery process for the two most common platforms on which the Agent runs.

Agent Discovery Process for NT

At agent startup, a script is executed which reads configuration parameters from the Windows NT registry, the listener.ora file, and the tnsnames.ora file (if it exists).

The agent discovers new services on the machine where it is installed and creates/rewrites/appends to its configuration files: snmp_ro.ora, snmp_rw.ora, and services.ora.

To determine what services are available on its machine (services that the agent will manage), the agent uses the following discovery algorithm:

The agent records the ORACLE_SID and ORACLE_HOME information for each database service found in the Windows NT Registry.
Based on the values found in the Windows NT registry, the agent reads the listener.ora files to determine which listeners service which databases. The location of the listener.ora configuration files is based on the SQL*Net configuration file locations. For example, the TNS_ADMIN environment variable and the location of the $ORACLE_HOME/network/admin directory are based on the ORACLE_HOME information found in the Windows NT registry.
The name of the discovered databases is based on the GLOBAL_DBNAME parameter defined in the listener.ora file for that database.
If GLOBAL_DBNAME parameters are not found in listener.ora, the agent searches for a tnsnames.ora file using the same search methodology used to find the listener.ora file.
If the tnsnames.ora file is not found, the database alias, <SID>_<hostnames>, is assigned to a database service. The service will be known to the agent by this alias, and it will be visible as such at the Oracle Enterprise Manager Console.

Note:
If multiple aliases exist for the same instance in the TNSNAMES.ORA, the agent will use the one listed first. If you prefer to use a different alias, reorder the TNSNAMES.ORA entries and restart the Agent.
If a database or any other new service is installed on the node where the agent resides, the agent must be restarted to add the new service to the agent configuration files.

Agent Discovery Process for UNIX

At startup, the agent discovers new services on the machine where it is installed and creates its configuration files: snmp_ro.ora, snmp_rw.ora, and services.ora.

To determine what services are available on its machine (services that the agent will manage), the agent uses the following discovery algorithm

The agent reads the oratab file for values of all the Oracle Homes and SIDs. Depending on the platform, the oratab file can be located in either of the following locations:
- /etc
- /var/opt/oracle
Based on the Oracle Homes values found in oratab, the agent searches for the listener.ora files to determine which databases are serviced by which listeners.
The name of the discovered databases is based on the GLOBAL_DBNAME parameter defined in the listener.ora file for that database.
If GLOBAL_DBNAME parameters are not found in listener.ora, the agent searches for a tnsnames.ora file using the same search methodology used to find the listener.ora file.
If the tnsnames.ora file is not found, the database alias, <SID>_<hostnames>, is assigned to a database service. The service will be known to the agent by this alias, and it will be visible as such at the Oracle Enterprise Manager Console.

1 Intelligent Agent Overview