1 Overview of Oracle SNMP Support

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

• Benefits of Oracle SNMP Support

• How SNMP Works

• The Components of SNMP

• How SNMP Communications Are Performed

• Oracle Enterprise Manager and SNMP

• Management Information Base (MIB)

The Simple Network Management Protocol (SNMP) is a protocol used for 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:

• The monitoring of key Oracle products is quickly integrated into any management framework based upon SNMP.

• These Oracle products are located, identified, and monitored in real time across enterprise networks of any size.

• Administrators see standard Oracle icons that represent Oracle products in a network map. You can dynamically customize this map. In fact, administrators can define and customize various network maps for different purposes.

• Administrators see the current status of Oracle products, as shown by several status variables that are defined for each product in a management information base (MIB), or they can select which elements to view by their status.

• Administrators can anticipate exceptional conditions by defining thresholds and alerts, to respond to special situations as soon as they occur or to enable automatic responses.

• Administrators can more readily determine key characteristics of Oracle objects, such as database size, number of users, and activity level.

• Administrators can store and analyze historical data that has been obtained through SNMP.

• Providers of management applications can easily build customized solutions for Oracle customers because SNMP is an open standard.

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.

Note:

Oracle SNMP is not supported on HP OpenVMS platform.

How SNMP Works

SNMP 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. Managed elements can be network components such as bridges, routers, 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 standalone workstation that is on the same network 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:

• A management platform or framework. At least one general purpose management application is required.

• A repository to store historical data regarding system activity, for reporting, displaying, or accounting. Some frameworks do offer an Oracle database as a repository, but in other cases the format of the repository is set.

• Various third-party specialized management applications. These are optional add-in components that often integrate with the framework and provide more in depth management of particular devices or applications.

Note:

These components are not part of Oracle SNMP support.

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

Description of "Figure 1-1 Basic Components of Oracle SNMP Support"

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 CA Unicenter, HP OpenView, Tivoli NetView, Aprisma Spectrum, Sun Solstice, Castle Rock SNMPc Network Manager.

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:

• Maps illustrating logical or physical network topologies.

• Icons representing individual network components.

• Graphing tools such as dials, bar charts, line plots, and so on, for effective monitoring of management information variables.

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.

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 a master 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 a management agent can manage multiple elements on the same node, the set of elements that it can manage is fixed when the management 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 to manage. 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 master 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). 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.

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.

Oracle Enterprise Manager and SNMP

Enterprise Manager web-based architecture provides a monitoring and administrative framework that is globally scalable and easy to deploy. SNMP extends Enterprise Manager's monitoring capabilities to any SNMP-enabled entity within your managed environment. For more information about Enterprise Manager, its functionality, and architecture, see the Oracle Enterprise Manager Concepts guide.

SNMP Trap Notification

Using the Enterprise Manager notification system, you can take advantage of SNMP-enabled third-party applications such as HP OpenView. For example, you may want to send third-party applications a notification from Enterprise Manager when a certain metric has exceeded a threshold. Using SNMP Traps with the notification system is a simple matter of defining a notification method that uses an SNMP Trap. Instructions for setting up a notification method using an SNMP Trap can be found in the next chapter.

SNMP Fetchlets

Fetchlets are parameterized data access mechanisms available to map relevant data from a managed element into Enterprise Manager's metric format. In the standards area, Enterprise Manager currently uses SNMP Fetchlets to fetch information from SNMP-enabled entities within your managed environment.

The SNMP Fetchlet mechanism is defined in the “query descriptor“ section of the metadata.xml configuration file. Example 1-1 shows a sample metadata.xml configuration file that has SNMP Fetchlets defined for collecting metric information.

Example 1-1 SNMP Fetchlets Used in metadata.xml Configuration File

<Metric NAME="Load" TYPE="TABLE">
    <Display>
      <Label NLSID="cisco_router_load">Load</Label>
    </Display>
 
    <TableDescriptor>
     <ColumnDescriptor NAME="busyPer" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_busyPer">CPU Busy in the last                                                                                  5 seconds (%)</Label>
        </Display>
     </ColumnDescriptor>
 
     <ColumnDescriptor NAME="avgBusy1" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_avgBusy1">CPU Busy in the last 
        minute(%)</Label>
        </Display>
     </ColumnDescriptor>
 
     <ColumnDescriptor NAME="avgBusy5" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_avgBusy5">CPU Busy in last 5 minutes (%)</Label> 
        </Display>
     </ColumnDescriptor>
    </TableDescriptor>
 
    <QueryDescriptor FETCHLET_ID="Snmp">
      <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
      <Property NAME="hostname" SCOPE="INSTANCE">agentHost</Property>
      <Property NAME="TABLE"    SCOPE="GLOBAL">FALSE</Property>
      <Property NAME="OIDS"     SCOPE="GLOBAL">1.3.6.1.4.1.9.2.1.56.0
                                               1.3.6.1.4.1.9.2.1.57.0
                                               1.3.6.1.4.1.9.2.1.58.0
        </Property>
    </QueryDescriptor>
</Metric>

For Enterprise Manager 10g Grid Control Release 2 or lower, that is 10.2.0.2 or 10.2.0.1, you can only collect integer and string values from third-party, SNMP agents. This is because only SNMP version v1 is supported in the Fetchlet. Therefore, any integer value collected from the third-party, SNMP agent through SNMP v1 is accommodated in 32 bits.

For Enterprise Manager 10g Grid Control Release 3 or higher, that is 10.2.0.3 or higher, you can use counter64 data type objects in your metadata.xml file to collect not only 32-bit integer and string values, but also 64-bit integer values.

By this, we can classify SNMP agents into two broad categories, mainly:

• SNMP v1 Agent that responds only to SNMP v1 queries

• SNMP v2 Agent that responds to SNMP v1 and v2 queries

In order to collect these counter64 values, you need to add one more query descriptor property called VERSION in the metadata.xml file. This is to intimate the Fetchlet to make appropriate version of SNMP request to fetch the data from the SNMP target.

For example, if the Fetchlet has to collect ifHCInOctets (64-bit value) attribute from the third-party, SNMP target, then the query descriptor definition in the metadata.xml file will look like this:

<QueryDescriptor FETCHLET_ID="Snmp">
      <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
      <Property NAME="hostname" SCOPE="INSTANCE">NAME</Property>
      <Property NAME="COMMUNITY" SCOPE="INSTANCE"
      OPTIONAL="TRUE">CommunityString</Property>
      <Property NAME="VERSION" SCOPE="GLOBAL">V2c</Property>
      <Property NAME="OIDS" SCOPE="GLOBAL">1.3.6.1.2.1.31.1.1.1.6 </Property>
</QueryDescriptor>

If the VERSION property value is set to V1 or if the VERSION property is not at all mentioned in the query descriptor, then the Fetchlet make only SNMP v1 query to collect the metric values, that is it collects only 32-bit integer and string values.

There may be occasions when you will want the Fetchlet to collect some metric columns from SNMP v1 Agent and some from SNMP v2 Agent. In this case, define the metrics using ValidIf tag based on the SNMP target version, that is if SNMP version is != v1, then counter64 data type property needs to be included in the metric definition; otherwise this property should be ignored. Here, the SNMP target version can be identified using a dynamic property.

For example, if you want to collect 1.3.6.1.2.1.31.1.1.1.5 (integer type) from SNMP v1 Agent switch device, and 1.3.6.1.2.1.31.1.1.1.5 (integer type) and 1.3.6.1.2.1.31.1.1.1.6 (Counter64 type) from SNMP v2 Agent switch, then your metric definition should look like this:

<Metric NAME="Table"  TYPE="TABLE">
   <ValidIf>
   <CategoryProp NAME="SnmpAgentVerision" CHOICES="V1"/>
   </ValidIf>

   <Display>
   <Label NLSID="SwithIfTable">SwitchInterface</Label>
   </Display>

   <TableDescriptor>
   <ColumnDescriptor NAME="Column1" TYPE="NUMBER">
      <Display>
      <Label NLSID="Column1">Column1 Value</Label>
      </Display>
   </ColumnDescriptor>
   </TableDescriptor>

   <QueryDescriptor FETCHLET_ID="Snmp">
   <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
   <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property>
   <Property NAME="COMMUNITY" SCOPE="INSTANCE"  
   OPTIONAL="TRUE">CommunityString</Property>
   <Property NAME="TABLE" SCOPE="GLOBAL">TRUE</Property>
   <Property NAME="VERSION" SCOPE="GLOBAL">V1</Property>
   <Property NAME="OIDS" SCOPE="GLOBAL"> 1.3.6.1.2.1.31.1.1.1.5 </Property>
   </QueryDescriptor>
</Metric>


<Metric NAME="Table"  TYPE="TABLE">
   <ValidIf>
   <CategoryProp NAME="SnmpAgentVerision" CHOICES="V2"/> 
   </ValidIf>

   <Display>
   <Label NLSID="SwithIfTable">SwitchInterface</Label>
   </Display>

   <TableDescriptor>
   <ColumnDescriptor NAME="Column1" TYPE="NUMBER">
      <Display>

      <Label NLSID="Column1">Column1 Value</Label>
      </Display>
   </ColumnDescriptor>   
      
   <ColumnDescriptor NAME="Column2" TYPE="NUMBER">
      <Display>
      <Label NLSID="Column2">Column2 Value</Label>
      </Display>
   </ColumnDescriptor>         
   </TableDescriptor>
   
   <QueryDescriptor FETCHLET_ID="Snmp">
   <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
   <Property NAME="hostname" SCOPE="INSTANCE">NAME</Property>
   <Property NAME="COMMUNITY" SCOPE="INSTANCE"
   OPTIONAL="TRUE">CommunityString</Property>
   <Property NAME="TABLE" SCOPE="GLOBAL">TRUE</Property>
   <Property NAME="VERSION" SCOPE="GLOBAL">V2c</Property>
   <Property NAME="OIDS" SCOPE="GLOBAL"> 1.3.6.1.2.1.31.1.1.1.5
                                         1.3.6.1.2.1.31.1.1.1.6
   </Property>
   </QueryDescriptor>
</Metric>

Here, the SnmpAgentVersion is being calculated by using the following dynamic property definition:

<DynamicProperties NAME="SnmpVersionConfig" FORMAT="ROW" OPT_PROP_LIST="SnmpVersionIdentifier>
   <QueryDescriptor FETCHLET_ID="Snmp">
   <Property NAME="NAME" SCOPE="INSTANCE">NAME</Property>
   <Property NAME="hostname" SCOPE="INSTANCE">AgentHost</Property>
   <Property NAME="COMMUNITY" SCOPE="INSTANCE"
   OPTIONAL="TRUE">CommunityString</Property>
   <Property NAME="TIMEOUT" SCOPE="INSTANCE" OPTIONAL="TRUE">Timeout</Property>
   <Property NAME="VERSION" SCOPE="GLOBAL">V1</Property>
   <Property NAME="OIDS" SCOPE="GLOBAL"></Property>
   1.3.6.1.6.3.1.1.6.1.0
   </QueryDescriptor></DynamicProperties>

<DynamicProperties NAME="SnmpVersionValues" FORMAT="ROW" PROP_LIST="SnmpAgentVersion">
   <QueryDescriptor FETCHLET_ID="VersionRangeComputer">
   <Property NAME="Version" SCOPE="INSTANCE"
   OPTIONAL="TRUE">SnmpVersionIdentifier</Property>
   <Property NAME="DefaultRange" SCOPE="GLOBAL">V1</Property>
   <Property NAME="V2" SCOPE="GLOBAL">0;</Property>
   </QueryDescriptor>
</DynamicProperties>

First, SnmpVersionIdentifier is being calculated based on one of the SNMP v2 MIB standard OID 1.3.6.1.6.3.1.1.6.1.0. Any bi-lingual standard Agent must have implemented this OID.

So when we try to collect the value for this OID via V1 request, if the agent is an SNMP v2 Agent, then we should get an integer value (range from 0-2147483647). However, if the agent is an SNMP v1 Agent, then we will get nosuchname error for this request.

Finally, an understandable format of SnmpAgentVersion values (v1 or v2) is being calculated using the VersionRangeComputer Fetchlet based on the value of SnmpVersionIdentifier.

Note:

In this example, you can also specify any other application specific OID (instead of 1.3.6.1.6.3.1.1.6.1.0) to discover the SnmpAgentVersion, provided you know that that particular OID is implemented in the target SNMP agent and can be used to differentiate v1 and v2 SNMP Agents.

Note:

For more information about Fetchlets, refer to Oracle Enterprise Manager Extensibility Guide available at:

http://www.oracle.com/technology/documentation/oem.html

SNMP Receivelets

While monitoring third-party entities in your managed environment, if the status of a third-party network element turns unavailable or if its metric severity conditions (metric thresholds) are met or exceeded, the SNMP Agent of that third-party network element sends a notification to Oracle Management Agent. These notifications may be in the form of SNMP Traps that get triggered asynchronously upon reaching the performance thresholds, and without any requests from Oracle Management Agent.

Since these traps are based on SNMP, Oracle Management Agent uses SNMP Receivelets to receive and translate these SNMP Traps into a form compatible with Oracle Management Service.

Once the SNMP Traps are received, the SNMP Receivelet extracts information pertaining to only those object identifiers (OIDs) that are defined in the “push descriptor“ section of the metadata.xml configuration file (that is only for those third-party network elements that need to be monitored by Enterprise Manager). Example 1-2 shows how SNMP Receivelets are defined in the metadata.xml configuration file.

Example 1-2 SNMP Receivelet Defined in metadata.xml Configuration File

<Metric NAME="Load" TYPE="TABLE">
    <Display>
      <Label NLSID="cisco_router_load">Load</Label>
    </Display>
 
    <TableDescriptor>
     <ColumnDescriptor NAME="busyPer" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_busyPer">CPU Busy in the last 5 seconds (%)</Label> 
        </Display>
     </ColumnDescriptor>
 
     <ColumnDescriptor NAME="avgBusy1" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_avgBusy1">CPU Busy in the last minute(%)</Label> 
        </Display>
     </ColumnDescriptor>
 
     <ColumnDescriptor NAME="avgBusy5" TYPE="NUMBER" IS_KEY="FALSE">
        <Display>
          <Label NLSID="cisco_router_load_avgBusy5">CPU Busy in last 5 minutes (%)</Label> 
        </Display>
     </ColumnDescriptor>
    </TableDescriptor>
 
<PushDescriptor RECVLET_ID="SNMPTrap">
<Property NAME="MatchEnterprise" SCOPE="GLOBAL">1.3.6.1.4.1.529</Property>
  <Property NAME="MatchGenericTrap" SCOPE="GLOBAL">6</Property>
  <Property NAME="MatchSpecificTrap" SCOPE="GLOBAL">50</Property>
  <Property NAME="MatchAgentAddr" SCOPE="INSTANCE">AdminAddress</Property>
  <Property NAME="EventbusyPerOID" SCOPE="GLOBAL">1.3.6.1.4.1.9.2.1.56.0</Property>
  <Property NAME="SeverityCode" SCOPE="GLOBAL">CRITICAL</Property>
 </PushDescriptor>
</Metric>

Whenever an SNMP Trap is sent by the SNMP agent upon reaching the threshold value, the SNMP Receivelet receives those traps based on the SNMP Agent configuration, translates them to an Enterprise Manager understandable format (like event or datapoint based on the push descriptor information), and stores that information (in XML files) in the upload directory. The Upload Manager checks for such new files in the upload directory, and then uploads those files onto Oracle Management Service. Enterprise Manager, then, accesses the Oracle Management Service to extract the collected information and display it to the user.

Note:

For more information about Receivelets, refer to Oracle Enterprise Manager Extensibility Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Enterprise Manager SNMP Subagent

In Enterprise Manager 9.x and earlier releases, the Enterprise Manager SNMP Subagent functionality was integrated with Oracle Management Agent (formerly known as the Intelligent Agent). For Enterprise Manager release 10.x, SNMP subagent functionality now exists as a standalone executable that is installed along with Oracle Management Agent. The Enterprise Manager SNMP Subagent listens to SNMP requests and queries the database to obtain results from the subagent.

Management Applications can directly communicate with the Enterprise Manager SNMP Subagent using SNMP protocol on supported platforms. The Enterprise Manager SNMP Subagent provides access to Oracle's database Management Information Base (MIB) variables.

Oracle SNMP support is provided for the following:

• Oracle Database Server

• Oracle Network Listener Server

• Oracle Enterprise Manager

Since Oracle Management Agent and Enterprise Manager SNMP Subagent are separate processes, the Enterprise Manager SNMP Subagent cannot send out SNMP Traps. Hence, you cannot tie an alert to with the sending of an SNMP Trap, as was possible with 9.x and earlier versions of the Intelligent Agent. However, the Enterprise Manager SNMP Subagent does send standard RDBMS traps when the database goes down.

Management Information Base (MIB)

While SNMP allows Enterprise Manager to send information to third-party SNMP-enabled applications, there may be situations where you want SNMP-enabled applications to obtain information from Enterprise Manager. This is accomplished with the help of MIB variables, and by signing up for SNMP Traps.

IMPORTANT:

A valid Diagnostic Pack license is required to use the Enterprise Manager MIB variables.

A 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. 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.

• the variable's name

• the Object Identifier (OID) of the variable

• the variable's data type

• the access rights associated with the variable

• a textual description of the meaning of the 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 OIDs 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:

• the Oracle Database MIB

• the Oracle Listener MIB

Figure 1-2 The MIB Hierarchy

Description of "Figure 1-2 The MIB Hierarchy"

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

For more information on MIB, see Chapter 3, "Oracle MIB Overview" and Chapter 4, "Reading the MIB Variable Descriptions".