Re: Custom OEM event

"Chuck" <chuckh_nospam_at_softhome.net> wrote in message news:Xns9445946ADA16Echuckhsofthomenet_at_130.133.1.4...
> >
> > "Chuck" <chuckh_nospam_at_softhome.net> wrote in message
> > news:Xns94455C169629chuckhsofthomenet_at_130.133.1.4...
> >> Has anyone ever written a custom OEM event they'd be willing to share
> >> that checks the number of times a segment can extend before running
> >> out of space? I don't want to use the prepackaged Tablespace Full or
> >> Chunk Small events as they both fall short of what I want. I size my
> >> extents to give me 3-4 days of growth. I want to alarm when there are
> >> 2 free extents remaining. Chunk small requires the free extents to be
> >> contiguous which isn't always the case and yields plenty of false
> >> alarms. Tablespace full is based on percentages and the threshholds
> >> would constantly need to be tweaked as the tablespace grows. Since my
> >> tablespaces are all LMT's, I'm looking for something that just
> >> divides the total free space available in the tablespace by the next
> >> extent size. It sounds simple but I haven't had time to write
> >> something and integrate it with OEM. I was hoping someone else has
> >> already done it and would be willing to share what they've done.
> >>
> >> Our environment is a 9.2 OMS, with agents ranging from 8.1.7.4 up
> >> through 9.2.
> >> --
> >> Chuck
> >> Remove "_nospam" to reply by email
> >
> >
> >
>
> The databases I'm concerned about are 8i with LMT's. I'm concerned about
> running out of space in a tablespace. It's not about number of extents in
> a segment. I just want to know when I've got about a weeks worth of space
> left so I can add a datafile.

I still don't understand. If you're going to add a datafile in any case, presumably there's sufficient physical disk space to do so with ease. So if there space is there anyway, why not allocate it up-front? Add in what you consider to be sufficient datafile space for, say, a year's worth of table growth, and have done with it. Space management is not, or should not be, the concern it once was.

(The issue about DMTs by the way was not so much the number of extents, because that mostly affected only DDL statements, but the fact that acquiring an extent in the first place required extensive querying of the data dictionary, and extensive DML, with all the redo and rollback that entailed. Extent allocation was slow and expensive, and people would wait for it to happen if it happened often enough.)

Regards
HJR Received on Tue Dec 02 2003 - 13:46:52 CST