For easy reference, tables listing the object identifiers for each object of a given Oracle-implemented MIB can be found in the appendix covering that MIB.
An example OID for an private Oracle MIB variable follows:
1.3.6.1.4.1.111.9999.1.8.1.1
In this OID:
elements listed above are assigned by entities outside Oracle. Thus, all objects within the Oracle ID space (that is, those objects to which Oracle has assigned OIDs), share the root OID 1.3.6.1.4.1.111. Continuing use of the above example OID for illustration, Oracle has defined the elements of its private ID space as follows:
An example OID for a public RDBMS MIB variable follows:
1.3.6.1.2.1.39.1.2.1.3
In this OID, the first four elements (1.3.6.1) match those for the Oracle root ID, indicating that this object falls under the iso, org, dod and internet objects. The fifth element (2), however, indicates that this object falls within the Internet management OID space. The seventh element (39) indicates that this object falls within the public RDBMS MIB. All variables of the public RDBMS MIB share this root OID of 1.3.6.1.2.1.39 The ninth element (2) indicates that this object is part of the rdbmsDbInfoTable. The eleventh element (3) identifies this as the leaf object rdbmsDbInfoSizeUnits.
An example OID for a public Network Services MIB variable follows:
1.3.6.1.2.1.27.1.1.1.6
In this OID, the first four elements (1.3.6.1) match those for the Oracle root ID, indicating that this object falls under the iso, org, dod and internet entities. The fifth element (2), however, indicates that this object falls within Internet management OID space. The seventh element (27), indicates that this object falls within the public Network Services MIB. All variables of the public Network Services MIB share this root OID of 1.3.6.1.2.1.27. The ninth element (1) indicates that this object is part of the applTable. The tenth element (6) identifies this as the leaf object applOperStatus.
Not all variables are indexed on a per-service basis, as described above. It is also possible for a variable to have many instances for a single database. For example, while rdbmsSrvParamEntry describes a single database configuration parameter, that same managed node will have many instances of rdbmsSrvParamName.
To uniquely identify the multiple instances of these variables, each MIB table is indexed by one or more variables which, together, uniquely identify the rows of the table. (These index variables are conceptually equivalent to the primary key of a relational database table.) To refer to a particular instance of a variable, concatenate the variable's OID with the values of the index variables of the MIB table to which the variable belongs.
For instance, rdbmsDbName is defined within the rdbmsDbTable, which is indexed by the variable rdbmsDbIndex. For example, assume two databases are running on a host, one with SNMP index 2, the other with SNMP index 4. Then the name of the first database can be specified by concatenating the OID for rdbmsDbName (1.3.6.1.2.1.39.1.1.1.4) with the appropriate value of rdbmsDbIndex (2), or 1.3.6.1.2.1.39.1.1.1.4.2. Similarly, the name of the second database is the value of 1.3.6.1.2.1.39.1.1.1.4.4.
If a table is indexed by more than one variable, add the appropriate value of each index variable to the end of the OID, in the order they are listed in the table's MIB definition INDEX clause, separated by dots. The size (oraXDbDataFileSizeAllocated, or 1.3.6.1.4.1.111.9999.1.3.1.3) of the fifth data file (5) of the second database on the above host (whose rdbmsDbIndex is 4) is the value of 1.3.6.1.4.1.111.9999.1.3.1.3.4.5.