Re: OEM custom events

From: Chuck <chuckh_at_softhome.net>
Date: 5 Aug 2003 13:57:01 GMT
Message-ID: <Xns93CE6538C5CEBchuckhsofthomenet@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. Received on Tue Aug 05 2003 - 08:57:01 CDT