Re: OEM custom events

Chuck <chuckh_at_softhome.net> schreef in berichtnieuws Xns93CE6538C5CEBchuckhsofthomenet_at_130.133.1.4...
| Ed Stevens <nospam_at_noway.nohow> wrote in
| news:no9viv8in76uu23boq6bcb6ma55ld3lut0_at_4ax.com:
|
| > On 4 Aug 2003 19:34:35 GMT, Chuck <chuckh_at_softhome.net> wrote:
| >
| >>I am trying to set up a custom event in OEM 9.2. It looks like all you
| >>can return in a custom test is a single value (one row, one column). I
| >>want to return a value see if the event needs to be triggered and a
| >>more descriptive report if it is triggered. Knowing that a problem
| >>exists is almost useless unless you know where the problem is.
| >>
| >>For example I want to see if there are any segments that can allocate
| >>< 2 extents before the tablespace is out of space. I want a critical
| >>alert if 0 extents can be allocated and a warning if 1 can be. The
| >>problem is I can only return one row with one column to the event
| >>processor. When the event triggers the associated message is simply
| >>"current value: n" where n is 0 or 1. I want it to list all segments
| >>that are in danger of not allocating the next extent and how many
| >>extents they can allocate. Can this be done?
| >
| > Why not just use the stock "tablespace full" event?
|
| Because that is based on percent full and the tablespaces in question are
| so large they will always be at 99 percent full - even when there's enough
| room for the tables to grow for another month. The tablespaces will always
| be in warning or alarm state which is almost as bad as not monitoring them
| at all. I'm sure at some point the alarms will start being ignored.
|
| What I prefer to do is size my extents based on the growth rate of the
| object so that one extent represents 4-5 days of new data. Then I want to
| warn when there are only two free extents remaining in the tablespace, and
| alarm when only one remains. This gives me plenty of time to prevent a
| problem without the false hits that a percent full based solution would.
|
| I like the way the standard events work where they not only show the
| warn/alarm state (yellow or red), but also give details on what is
| triggering the event. In my case I want to know which tablespace is
nearing
| capacity without having to run a 2nd script. If I use a "custom sql
| test" all I can return is a single value showing that a problem existsI
| want to also show where the problem is. I am afraid I may have to write a
| shell based solution that runs from cron and does not show up in the OEM
| console. I am trying to avoid this.
|
| > Doesn't really matter *which* segment is about to fill it up. In
| > fact,with 9.x you should be using LMT and uniform extents, if any
| > one segment is about to take the last two extents,
| > then all segments are equally "at fault."
|
| Already am using LMT's and uniform extents. Haven't created any other type
| of tablespace since 8i.
|

We use OEM but I have not yet created a fix-it job. So I'am not sure if next idea is possible.
You define a fix-it job for your custom sql test. When it raises a warning or alarm the fix-it job will start and report you (via email or so) the required details.

Another wild idea could be to add your own tcl script to the OEM collection. Never found (nor searched) in the documentation if adding tcl scripts is possible. If not it will require some hacking to have this added to the list of events OEM presents, if possible at all. Not supported ofcourse. And you must know how to write tcl scripts..... Received on Tue Aug 05 2003 - 15:15:38 CDT