Re: dbsnmp: one Sun box quits answering for one OID for MRTG
- From: Robert Eskridge <bryny@xxxxxxxxxxx>
- To: Robert Eskridge <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Feb 2004 16:25:08 -0600
Ah well, never mind. I continued to cruise metalink with various
searches and with a search on "rdbmsRelState" I stumbled on the
answer. Prompted by note 1061946.6, I compared the databases listed
in the snmp_rw.ora file to those in the oratab and found that the
snmp_rw.ora still had a reference to a discontinued database. Doing
the little stop/edit/start magic cleared up the problem.
(Doesn't it always work that way, you find the answer in the docs
after you've posted a question to the list. Maybe that's how I should
just start working on a problem.... :-)
-rje
R> We use MRTG to do some monitoring of our 8.1.7 databases that are
R> running on Solaris 9 Sparcs, mostly as a visual tool to look back and
R> see when certain things started to happen.
R> Our MRTG config uses the perl snmp modules to grab stuff from the
R> various machines. One of our long gone DBA's grabbed the scripts from
R> who knows where. It's been working fine, but I've notice that one of
R> our remote machines has quit answering for just one of the OID's that
R> the scripts ask for:
R> # Database State
R> $oid[0] = '.1.3.6.1.2.1.39.1.9.1.1.2.2';
R> This one machine just suddenly quit liking this particular request:
R> $snmpget -c public -v1 -Ou z1 .1.3.6.1.2.1.39.1.9.1.1.2.2
.1.3.6.1.2.1.39.1.7.1.4
R> .5.7.100.98.95.110.97.109.101.1 enterprises.111.4.1.1.1.2.5
enterprises.111.4.1.
R> 1.1.4.5 enterprises.111.4.1.1.1.8.5
R> Error in packet
R> Reason: (genError) A general failure occured
R> Failed object: 39.1.9.1.1.2.2
R> 39.1.7.1.4.5.7.100.98.95.110.97.109.101.1 = STRING: "DEV"
R> enterprises.111.4.1.1.1.2.5 = Counter32: 118585464
R> enterprises.111.4.1.1.1.4.5 = Counter32: 1079032
R> enterprises.111.4.1.1.1.8.5 = Counter32: 66598668
R> Curiously, the script never uses the value once it has it, but it's
R> annoying that a machine that is supposed to be identically configured
R> to several other machines quits responding with no apparent
R> provocation for one OID, but continues to answer for the others.
R> I say supposed to be configured identically, but we're not absolutely
R> sure. We inherited the machine from a sister company and they were
R> supposed to configure it to our instruction. It was responding as
R> expected then just stopped on a day when no changes were being made.
R> I know there must be some difference as I do see one apparently snmp
R> related process running on the machine that I don't see on the others,
R> atmsnmpd.
R> I've made my scripts work again by removing the offending but unused
R> OID. But I just don't like it when something changes with no
R> explanation.
R> Has anyone seen this before when playing with dbsnmp?
R> -rje
R> ----------------------------------------------------------------
R> Please see the official ORACLE-L FAQ: http://www.orafaq.com
R> ----------------------------------------------------------------
R> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
R> put 'unsubscribe' in the subject line.
R> --
R> Archives are at //www.freelists.org/archives/oracle-l/
R> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
R> -----------------------------------------------------------------
-rje
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
