Release 1.6
A63731-01
Library |
Product |
Contents |
Index |
| Oracle
Enterprise Manager Administrator's Guide
Release 1.6 A63731-01 |
|
The Oracle Enterprise Manager Console works with Intelligent Agents and a Communication Daemon to gather information about the network environment, communicate with network objects, and manage jobs and events. Topics discussed in this chapter include:
The agents are intelligent processes running on remote nodes 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 agents are responsible for:
For information on configuring the agent, see the Oracle
Enterprise Manager Configuration Guide and the Oracle server platform-specific
installation documentation for your system.
Intelligent Agents are autonomous because they function without
requiring that the Console or daemon 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 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 (Unix platform).
The agent queues a maximum of 500 messages. After the limit
is reached, the oldest messages are dropped.
The agents are responsible for executing jobs and monitoring
for events. 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.
Because jobs can be long-running or complicated tasks, such as a database
backup job, the agent does not execute the job in its process space. Jobs
are run in a separate process. When the job is completed, the agent sends
the results to the Communication Daemon. In contrast, event scripts are
typically run directly by the agent. Event scripts are used for detecting
exceptions and are expected to have short execution times.
When the daemon sends a message to an agent on behalf of
an administrator logged into the Console, the daemon sends the agent 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.
Network encryption can be accomplished with the Advanced
Networking Option (ANO) option of Net8. ANO uses a sophisticated algorithm
to provide encryption on the Transparent Network Substrate (TNS) connections.
When the agent supports direct TCP/IP connections, as an option instead
of TNS, ANO features are still accessible. For information on ANO, see
the Net8 Administrator's Guide. For SQL*Net installations, network
encryption can be accomplished with the Oracle Secure Network Services
(SNS) option.
The agents support SNMP, so applications can communicate
directly with the agent using SNMP protocol. The agents provide access
to Oracle's database Management Information Base (MIB) variables. Although
the agent supports SNMP, the Communication Daemon does not use that protocol
to communicate with the agent. 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.
The Communication Daemon is a process that runs with the Console on the client machine. There is one Communication Daemon for each Console. The Communication Daemon is responsible for:
The Communication Daemon is implemented as a multi-threaded
process. For example, separate threads in the daemon perform activities
such as submitting jobs and events to agents, discovering new services
in the network, or receiving messages from agents. Because the daemon's
threads operate independently, the daemon can perform various operations
simultaneously and perform efficiently in large busy distributed environments.
Communication between the daemon and the agents is vital
to the Job and Event systems. The daemon must be able to send messages
to the agents in order to submit jobs and events. The agents must be able
to send messages to the daemon to report results and status messages for
the jobs and events.
The daemon and agents communicate using Oracle Remote Operations,
which is a remote procedure call mechanism based on the Transparent Network
Substrate (TNS). The daemon and agents can also use Oracle Secure Network
Services (SNS) to maintain the security of their network transmissions.
The daemon can communicate with any agent in the system, regardless of
the different protocols used in the distributed environment.
The daemon and agents use message queues for the messages
they send. Using queues ensures that no messages are lost even when the
Communication Daemon or agent is down. The daemon maintains several queues
for messages. The operations queue contains job and event requests sent
by the Console. For example, when you submit a new job to the Job system,
the Console queues the new job request on the daemon's operations queue.
When the daemon retrieves a job or event request from its
operation queue, it tries to contact the agent that should receive the
request. If it cannot contact the agent, the daemon places the request
in its failed queue. Periodically the daemon tries to contact the agent
which is responsible for the operation request in the failed queue. If
the daemon successfully contacts the agent, the operation request is removed
from the failed queue and sent to the responsible agent.
The daemon maintains a notification queue for job and event
notification. The notification queue contains messages about the status
of jobs and events. When the daemon receives a message from an agent regarding
a job or event, it places the message in the notification queue. When the
daemon changes the status of a job or event it also places a message in
the queue.
For example, when the daemon has successfully submitted a
new job to an agent, it places a message in the notification queue updating
the job's status to submitted. Messages in the notification queue are used
to update the job and event information stored in the repository.
In order for a daemon and an agent to pass messages, they
must establish a connection. Rather than requiring that the daemon or agent
create a new connection each time it wants to send a message, the daemon
maintains a cache of connections. If a connection is needed and it already
exists in the cache, it can be reused. This reduces the overhead involved
in creating new connections. Connections in the cache are aged out using
a least recently used algorithm.
The Oracle Daemon Manager allows you to manage communication between the Console's Communication Daemon and agents. The Daemon Manager Menu provides options for performing administration tasks. The Daemon Manager window provides a tree structure for viewing:
If you launch the Daemon Manager when Oracle Enterprise Manager
is not running, you can only configure the parameter settings.
The Agent Pending Operations folder lists the nodes that have pending job or event operations that have not been delivered to the agent. The nodes are listed in the following folders:
When viewing this folder, a multi-column list displays on
the right side of the screen. The list identifies the node name, the last
contact, the last connect attempted, and the number of job and event operations
for each node.
The Application Pending Notifications folder lists the third-party applications and users that have pending job or event notifications that have not been delivered to the agent. The applications and users are listed in the following folders:
When viewing this folder, a multi-column list displays on
the right side of the screen. The list identifies the username, application,
and number of job and event notifications for each application.
The Monitored Nodes folder lists the nodes that are being
monitored for the UpDown event. When viewing this folder, a multi-column
list displays on the right side of the screen. The list identifies the
node name, the last contact, and the last connect attempted for each node.
If you select a specific node in the tree, additional information identifies
the application and user for that node.
The Communication Daemon parameters and settings are viewed
and updated with Oracle Daemon Manager. The defaults are usually sufficient
to run Enterprise Manager. See Figure 6-1,
"Parameter Settings for the Communication Daemon" for an illustration
of the daemon parameters.
The parameters for the Communication Daemon include:
The listening address of the daemon. The default (Not Found) is actually:
(ADDRESS=(HOST=console_hostname)(PROTOCL=tcp)(PORT=7770)
If this address is changed, the setting must be a valid TNS
address. If this address is set, the daemon uses this address and the TCP/IP
Port setting is ignored.
The Listening Address parameter should be changed when:
When entering an address, make sure you are using a valid TNS address. For more information on TNS addresses, see the Oracle networking documentation, such as the Net8 Administrator's Guide or the Network Manager Administrator's Guide.
The TCP/IP port on which the daemon listens on. If the Listening Address parameter is not set, the daemon listens using TCP/IP with this port setting. The default is 7770. If an error message displays regarding "failed to listen for incoming requests", you may to need change the default value.
The number of open connections to agents. Default is 5 connections.
The frequency that the daemon checks for incoming data from an agent. Default is 3 seconds. This parameter is not used in this release.
Frequency that the daemon queries for additional services that have been added to the network. Default is 1800 seconds.
Frequency that the daemon checks to see if a node is up. This applies to nodes registered with the UpDown event. Default is 60 seconds.
Frequency that the daemon checks if a node is up after the node has been determined to be up and working. This can be set to a different value than the Node Heartbeat Timer so that a working node is checked at a less frequent interval. Default is 60 seconds.
Frequency that the daemon retries any failed operation. Default is 60 seconds.
The number of threads available. This setting should match the size of the connection cache. Default is 5.
Determines whether the user is registered at the computer where Enterprise Manager is started. If set to 1, the user is registered at the machine where Enterprise Manager is started. If set to 0, the registration is ignored. Default is 1.
Instructs the daemon to use PPP to establish communication
with the Agent when connecting to the network by modem. If set to 0, the
daemon will not use PPP. If set to 1, the daemon will use PPP to connect
to the Agent. The parameter must be set to 1 for both hosts with multiple
homes and machines that use only PPP. If PPP is not available and this
parameter is set to 1, an error message will result when the daemon attempts
to connect. The default value is 0.
The PPP support works only with Windows Socket (WinSock)
version 2.0 and above. If PPP is enabled, you must use the Windows Dial-Up
Networking application when dialing in to the network.
A new parameter setting is used the next time Enterprise
Manager is started. You must have permission to update the NT registry
to change the parameters.
The Daemon Manager menu options allow you to view and manage
event, job, and daemon operations.
The File menu provides the following option:
The Edit menu provides the following option:
Deletes the selected job operation from the tree, repository,
and the daemon queue. Also notifies the Console of the change.
When problems persist with a job or event operation, the
Console and agent may be out of sync. This can happen due to data corruption
or the accidental deletion of files. You may also need to delete the operation
in the files that the agent maintains on the node where the agent is running.
Those files are stored in the $ORACLE_HOME/network/agent directory (Unix
platform) and have a ".q" extension. The agent must be shut down and all
the ".q" files must be deleted. This removes all the jobs and events from
that node.
The Control Oracle Daemon menu provides the following options:
Forces the daemon to check for the current network objects.
Forces the retry of operations for all nodes. This is useful if the Console machine has been disconnected or if you are dialing into the network at intervals.
Forces the daemon to monitor (heartbeat) the nodes to see
if they are up.
The Node menu provides the following option:
Pings the monitored node to check whether the agent on the
node is running.
The Help menu provides the following options:
Displays the overview topic of help.
Displays version information about the program.
