Re: Predicting Growth.

fitzjarrell_at_cox.net wrote:
> Ben wrote:
> > Ent Ed. 9.2.0.5, DMT's on AIX5L
> >
> > There isn't really an accurate way to estimate growth of a database, is
> > there? I have a history of six months of my data file sizes, but even
> > with that there are too many variables envolved to determine that my
> > database is going to continue to grow at a rate of 50 gig per year.
> >
>
> You've added 25 gig of space in the last six months; how much of that
> has actually been consumed? You don't state that figure, and I doubt
> you've taken the time to investigate it.
>
> > Even if you assume a constant rate of growth, how would you base your
> > projection?
>
> On how much of that space is actually used. Funny that you don't have
> that information handy.
>
> >
> > For example, lets say my datafiles grew 25G over the last six months.
>
> So? Have you used all of that added space?
>
> > At the beginning of that six months my database was 100G that is 25%
> > growth over the past six months.
>
> No, it's a 25% increase in available space.
>
> > Now looking ahead for a year. My database is now 125G, 25% of that is
> > 31.25G. Then six months down the road the database will be 156.25G, 25%
> > of that is 39.06G, etc etc. But that original 25% figure was calculated
> > from the 100G incarnation of the database. So that won't work.
>
> What won't 'work' is your assumption that the overall datafile space
> somehow translates to actual data growth when, in fact, you have no
> information to prove that.
>
> > Do I then assume that my database will grow at a constant size instead
> > of %? So my 125G db will be 175G by this time next year.
>
> Only if you continue adding 25 gig allocations to it, whether or not
> you need them. You need to determine how much of that space is
> actually used, how much of that space is still available, and how long
> it will take to actually consume that space based upon actual table
> growth.
>
> > This seems
> > more accurate, but I still think there are just too many unknowns to
> > actually come to an accurate answer.
>
> They're unknown to YOU because you haven't done the necessary work to
> determine the actual growth of the data. I suggest you write some
> queries against dba_free_space, dba_segments and a few other data
> dictionary views/tables to report on the space actually occupied by
> data and track the available free space. Simply measuring datafile
> size does you absolutely no good except to show you how close your are
> to having a full file system.
>
>
> David Fitzjarrell

What's funny?? I wanted responses on predicting the growth of a database and you've went off on a tangent about me not knowing how much free space we have. What I think is funny is that you suggest to query dba_free_space to find the amount of free space when that would only paint part of the picture. I tend to use dba_free_space and the see_space script supplied by Johnathan Lewis to exam free space, when that is what I want to do. Thanks for the help. Received on Thu Sep 21 2006 - 07:25:56 CDT