Well, it’s been a little over a week since we’ve made our monitoring tools available to the open source community. It’s always a bit interesting to take something used internally and try to package it in such a way that it will be useful to others. I hope those of you who have downloaded Monocle have had an opportunity to install it and perhaps even give it a run! If you have questions, please don’t be shy!
In a week or two we’ll be releasing version 1.1 of Monocle, (we’d hate to be accused of possessing “idle hands”.) We’re particularly excited about this release as it integrates Oracle’s dbms_server_alert technology with Monocle, (dbms_server_alert technology is the same technology used by Oracle’s Grid product.) The good news is you’ll have over 100 new things you can monitor using Monocle/Nagios. The bad news is… you’ll have over 100 new things you can monitor using Monocle/Nagios! In all seriousness, depending on your situation there are probably a dozen or so of these new dbms_server_alert things you’ll want to pay attention to. Examples of some things you might choose to monitor are:
- Library Cache Hit Ratio – If this is low, you may need to bump up the library cache.
- Avg. No. Users Waiting On Concurrency – If this is high you may be experiencing latching and/or locking issues.
- Shared Pool Free Pct. – If this is low, you may be headed for the dreaded 4031 – unable to allocate memory error!
- Process Limit Pct – If you’re close to 100% you’ll need to increase “processes” in the init.ora.
- Long Table Scans – Doing a lot of these? You may have some sql to tune!
- Hard Parses Per Second – If this is high, you may have an issue with bind variables.
… and so I’m sure, you get the picture.
If you’re running a version of Oracle 10.1 there’s a small bug you should know about:
The job monitor won’t compile in Oracle 10.1 You can fix this by editing the package bg_job_monitor.pkg.
, NULL as dsj.schedule_type
Of course the above will be fixed in version 1.1.