Every row that is created in PostgreSQL gets a unique OID unless created WITHOUT OIDS. OIDs are autotomatically assigned unique 4-byte integers that are unique across the entire installation. However, they overflow at 4 billion, and then the OIDs start being duplicated. PostgreSQL uses OIDs to link its internal system tables together. To uniquely number columns in user tables, it is best to use SERIAL rather than OIDs because SERIAL sequences are unique only within a single table.

OIDs are PostgreSQL's answer to unique row ids. Every row that is created in PostgreSQL gets a unique OID. All OIDs generated during initdb are less than 16384 (from backend/access/transam.h). All user-created OIDs are equal or greater that this. By default, all these OIDs are unique not only within a table, or database, but unique within the entire PostgreSQL installation. PostgreSQL uses OIDs in its internal system tables to link rows between tables.

Please click to access a scan of the 2960 and 2800 mib trees. If you look at the OID for the dial-in page 1.3.6.1.4.1.1768.5.25.0, you can follow it down the page. The word "calldialin 25" tells you it is under the calldialin branch, in this case it is integer 5, and it is variable 25. To get all of the items that you can manage in the 2800, goto the HTTP managment system and click on SNMP. All of the MIBS are there at the top. Click and save all three.

OID is stored in the ObjectIdentifierValue class. Only MibValueSymbols have a value and even then not all values are OID:s. The proper way to get the OID is to first check for a MibValueSymbol and then for an ObjectIdentiferValue with the instanceof operator.

If you know in which MIB the OID belongs, you can use the Mib.getSymbolByOid() method. Otherwise you will have to search all loaded MIB:s for the best (longest) match using the same method.

The ObjectIdentifierValue class structures the OID:s in a tree structure. It also provides methods for retrieving the parent and child OID:s, making it possible to traverse the whole OID tree. If you only wish to traverse the OID tree for a certain MIB file, care must be taken to examine the symbols associated with each ObjectIdentifierValue. The OID tree is linked together between all the MIB:s loaded by the same MibLoader, so any OID:s not belonging to the right MIB must be filtered out.

Yes. Denika uses a report template system based on MRTG configurations. Templates can be created to trend any SNMP OID.

A persistence layer has been developed as part of the WAF for the purpose of encapsulating database access routines. This is desirable for at least two reasons: abstraction and database independence. By encompassing the SQL statements in Java objects, the database access routines are developed in a scalable environment. Also, the applications are isolated from the schema changes (which may occur in future versions) since the database access routines are encapsulated by a standard API.

Accessing a MIB object by name through the MIMIC APIs or GUI is a convenience (it is easier to remember a name, than a sequence of numbers). But, this convenience has a price in terms of efficiency: whenever a name is used, that name has to be converted to an OID using some sort of search. MIMIC has optimized this search to take advantage of localization of reference: when referring to names, one usually refers to localized names, eg. within a table.

I set translate_oids or translate_trap_oid to 1 or 3 in snmptt.ini, but the trap is not being logged with a long symbolic name. Why? A: The current version of Net-SNMP (5.0.9 at the time of this writing) and everything before it does not support including the module name (eg: IF-MIB::) when translating an OID and most of the 5.0.x versions do not properly tranlsate numeric OIDs to long symbolic names. A patch is available for 5.0.8+ that will appear in later releases of Net-SNMP (5.1.1+).