Skip Headers

Oracle SNMP Support Reference Guide
Release 9.2.0

Part Number A96672-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

1
Overview of Oracle SNMP Support

This chapter provides a brief overview of Oracle SNMP support, including:

The Simple Network Management Protocol (SNMP) is a protocol used for Internet network management. SNMP enables a single application to first retrieve information, then push new information between a wide range of systems independent of the underlying hardware.

Designed primarily for database, network, and system administrators, Oracle SNMP support integrates the management of Oracle products into a number of existing, widely-used management systems. This feature enables key Oracle products running anywhere on an enterprise's network to be located, identified, and monitored by a management station running at a centrally located node, in much the same way and using some of the same tools as traditionally have been used to monitor the activity of the network itself. It thereby integrates the tasks of database and of network administrators, enabling both to use some of the same tools and to better integrate their tasks. Tools using SNMP traditionally provide powerful features for monitoring network components. Oracle extends this power to enable SNMP monitoring of some of its own products.

Benefits of Oracle SNMP Support

The primary benefits of Oracle SNMP support include the following:

Strictly speaking, Oracle SNMP support is intended more for monitoring Oracle products than for managing them. Oracle SNMP support is invaluable for tracking the status of an entire network of Oracle applications -- first, to verify normal operations, and second, to spot and react to potential problems as soon as they are detected. However, for purposes of investigating and solving some problems, other Oracle tools such as Oracle SQL *Plus Worksheet may be more appropriate. This is because Oracle SNMP support is designed to query status, but not to change system parameters, whereas other tools are designed to set or tune system parameters. Oracle does not support using SNMP to change, as opposed to query, system parameters primarily because the security that SNMP currently can provide is not considered adequate.

How SNMP Works

SNMP (Simple Network Management Protocol) is a standard internet protocol enabling certain nodes in a network, the management stations or managing nodes, to query other network components or applications for information concerning their status and activities. Such a query is known as an SNMP poll. The items that can be so polled are called managed elements. Traditionally, managed elements were limited to network components such as bridges and routers, but recently the definition has been extended to include mission-critical applications such as databases.

The software used by a management station is called a management framework or management platform. The management framework uses the SNMP protocol to request information from agents on the nodes being managed, and those agents send back the appropriate responses. The agents can also, independently of the framework, transmit messages called traps to well-known addresses in response to specific events. This is done to enable quick and possibly automatic reactions to the specific conditions that the traps indicate.

All requests sent to a given network node are handled by the same master agent. This agent redirects the requests to the appropriate managed elements on the node, in some cases using subagents. The protocol used for this is not yet standardized and is not SNMP. The information that SNMP can obtain is described in a structure called a Management Information Base (MIB), which is located on the node of the managed element.

Figure 1-1 shows the components of a management station and of a sample managed node.

The Components of SNMP

The components shown in Figure 1-1 are explained in the sections that follow.

Management Station

The management station refers to a node from which managed elements are monitored using the SNMP protocol. Typically, it is a stand-alone workstation that is on the same network or internetwork as the managed elements. While this book will consistently use the term management station, other terms used for it include management console, management system, or managing node.

Requirements for Implementing Oracle SNMP Support

The following components are needed to implement Oracle SNMP support on the Management Station:

Management Framework

At the management station, the management framework uses SNMP to request management information from other nodes. The framework collects, graphs, and possibly acts on that SNMP data, and saves some or all of it in a repository for historical analysis and reporting. Management frameworks include many tools and options. In addition to directly requesting information from managed nodes, frameworks typically use daemons to alert them when a managed node has sent a trap in response to a specific set of conditions. The traps also can be used to trigger management applications.


Note:

Oracle does not provide the management framework.


Figure 1-1 Basic Components of Oracle SNMP support.

Text description of mgmtstn.gif follows.

Text description of the illustration mgmtstn.gif

Because most frameworks use SNMP as a basis for communication, Oracle products that support SNMP can be integrated into virtually every management framework. Examples of such frameworks include:

Most of today's management frameworks also provide a selection of graphical objects that management applications may use to build a graphical user interface that serves their particular needs, such as:

Management Application

The management applications are the tools integrated with the management framework to accomplish more specialized network or database tasks. These applications contain virtually all of the sophisticated logic associated with network management.

A customized management application can work with one or more frameworks (on different management stations) or run independently. Because Oracle SNMP support is equally accessible to any type of provider, there are many different ways that applications can utilize it.

A fundamental management application, often shipped by default along with the management framework, is one that is capable of discovering the network topology and collecting some basic identification information about each discovered network entity or service. Such an application, for instance, may discover all hosts in a subnet along with their vendor, location, and status. Using this information, the management application can subsequently build up logical maps of the environment.

Managed Node

The managed node is a platform, such as a UNIX server, on which elements to be monitored reside. In Figure 1-1, two managed elements -- an Oracle Database server and Oracle Names -- are located on the managed node.

Master Agent

The master agent is the process on a managed node that accepts queries, also called "polls", from the management framework and communicates with the elements to be managed in order to answer the query. It also can send SNMP traps independently in response to specific conditions. Only one master agent can exist on each managed node. Any node that does not have an agent will not be able to respond to SNMP requests, but this does not prevent other nodes on the network from doing so. In other words, it is not necessary that every node in a network be able to respond to SNMP, although this is normally desirable.

The master agent may be either monolithic or extensible. If it is monolithic, it communicates directly with the elements to be managed. Although such an agent can manage multiple elements on the same node, the set of elements that it can manage is fixed when the agent is created, because the monolithic agent itself is responsible for interfacing to the managed elements.

If, on the other hand, the master agent is extensible, it will use a specific subagent for each element it has toanage. That subagent is then responsible for interfacing to the element. In this scenario, new subagents can register with the master agent at any time, so new managed elements can be added dynamically.

Some operating systems supply only monolithic agents. In this case, Oracle provides a master agent that can effectively treat that monolithic agent as a subagent, enabling new managed elements to be added to the node dynamically.

Subagent

The subagent is a process that receives queries for a particular managed element from the master agent and sends back the appropriate answers to the master agent. One subagent exists for each managed element residing on the managed node (with the exception that a single subagent can handle multiple Oracle database instances on the same node). In Figure 1-1, one subagent is dedicated to the Oracle Database server application and another subagent is dedicated to the Names application. The subagent(s) and master agent communicate using a multiplexing protocol dictated by the master agent. There is no standard protocol for this connection, and, while a few protocols are widely used, none is a designated standard.

Notice that the subagent for the Database Server is a separate process that communicates with the server through Oracle Net (using the IPC protocol). The Oracle Names subagent, on the other hand, is embedded in the application software itself. Both of these approaches are acceptable, as the specific means the subagents use to extract SNMP values are opaque to the master agent and to the framework.

Oracle Enterprise Manager

Oracle Enterprise Manager is a system management tool which provides an integrated solution for managing a heterogeneous environment. It combines a graphical console, agents, common services, and tools to provide an integrated, comprehensive systems management platform for managing Oracle products.

Oracle Enterprise Manager does not use SNMP directly. Instead, it communicates with the agent over Oracle Net using Transparent Network Substrate (TNS) connections. The agent listens to SNMP requests and passes them on to Oracle Enterprise Manager.

Intelligent Agents

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 perform such tasks as running jobs and monitoring events. They are also responsible for handling SNMP requests, if SNMP is supported on the agent's platform.

The agents support SNMP so applications can communicate directly with the agent using SNMP protocol on supported platforms. The agents provide access to Oracle's database Management Information Base (MIB) variables. Although the agent supports SNMP, the Oracle Enterprise Manager Communication Daemon uses TNS to communicate with the agent. Therefore, with Oracle Enterprise Manager, you can submit jobs or events that access Oracle MIB variables through the Daemon even when the database resides on a platform that does not support SNMP.

Management Information Base (MIB)

A management information base (MIB) is a text file, written in ASN.1 notation, which describes the variables containing the information that SNMP can access. The variables described in a MIB, which are also called MIB objects, are the items that can be monitored using SNMP. There is one MIB for each element being monitored. Each monolithic or subagent consults its respective MIB in order to learn the variables it can retrieve and their characteristics. The encapsulation of this information in the MIB is what enables master agents to register new subagents dynamically -- everything the master agent needs to know about the subagent is contained in its MIB. The management framework and management applications also consult these MIBs for the same purpose. In Figure 1-1, two MIBs exist, one for the Oracle Server and one for Oracle Names. MIBs can be either standard (also called public) or proprietary (also called private or vendor).

The actual values of the variables are not part of the MIB, but are retrieved through a platform-dependent process called "instrumentation". The concept of the MIB is very important because all SNMP communications refer to one or more MIB objects. What is transmitted to the framework is, essentially, MIB variables and their current values.

All MIBs are, in fact, part of one large hierarchical structure, with leaf nodes containing unique identifiers, data types, and access rights for each variable and the paths providing classifications. There is a standard path structure that includes branches for private subtrees. A portion of this structure is shown in Figure 1-2.

Each leaf of this tree provides the following information about one MIB variable:

The variable's name is intended to be descriptive, whereas the OID is a number that describes the path taken through the tree to reach that variable. For example, the variable named sysContact, identified by the OID 1.3.6.1.2.1.1.4 (meaning iso.org.dod and so on), is a read-write string variable that contains contact information about the administrator of the underlying system.

All objects contained under the mgmt branch of Figure 1-2 (in other words, all objects with OID's beginning 1.3.6.1.2) are considered standard and are tightly regulated by the Internet Engineering Task Force (IETF). For example, the standard RDBMS MIB lives under the mgmt branch and is supported by all relational database servers that claim to be SNMP-enabled. Oracle further adds its own MIB objects under the private branch to increase the manageability of its products. The following MIBs are specific to Oracle Services and are found under the {private.enterprise.oracle} branch:

Figure 1-2 The MIB Hierarchy

Text description of mibhiera.gif follows.

Text description of the illustration mibhiera.gif

How SNMP Communications Are Performed

SNMP is based on connectionless communication between the framework and the managed nodes. Because most management information does not demand reliable delivery, SNMP packets are transmitted from one node to a well-known address of another node, but no verification of successful delivery is made. The penalty for the light-weight, connectionless SNMP communication is paid by the management applications, which need to verify that SNMP transactions get completed successfully within a reasonable amount of time. If SNMP packets get lost in the network, the application cancels the associated transaction and possibly re-initiates it.

The most popular SNMP implementation uses the User Datagram Protocol (UDP) over the Internet Protocol (IP), although implementations also exist over other protocols, such as Novell's Internetwork Packet Exchange (IPX) and Apple's AppleTalk.

SNMP Support On Oracle

SNMP support on Oracle is provided through the Intelligent Agent. The Intelligent Agent provides direct access to Oracle's database Management Information Base (MIB) variables. Oracle SNMP support is provided for the following:


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

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback