Well, here's how it's done: you get your business analysis team to
pull the growth numbers out of their a...nalysis and then you make
the prediction. An accurate prediction can be based on historic growth data,
if nothing changes. If there is a sudden change in business, your prediction
is no longer good. You cannot make an accurate growth prediction when you
create table. An attempt to do so is completely analogous to what Pythia,
the Oracle of Delphi was doing. Oracle of Delphi was an early leader in the
executive support systems area and is not to be confused with Oracle Corp.
The main method used by Oracle of Delphi was SQL, what was an abbreviation
for "Said Quixotically on Laurel".
Prediction in the situation you describe are, essentially, a blame game.
You get business analysts to make a prediction and when it fails, point the
finger toward them. That's one of the things that makes corporate life
interesting.
--
Mladen Gogala
Ext. 121
-----Original Message-----
From: Ranko Mosic [mailto:ranko.mosic_at_gmail.com]
Sent: Friday, August 26, 2005 11:00 AM
To: Christian.Antognini_at_trivadis.com
Cc: tomday2_at_gmail.com; Oracle-L
Subject: Re: Table growth - disk sizing
Back to the initial question ( requirement priority keeps changing -
now table growth is priority again):
I need to estimate table growth. Database is still not in production
so I can't track growth and predict table size in conventional way.
I am thinking on modeling table growth based on known number of transactions
per
year; finding how much disk space each transaction takes in each
table; then multiplying by number of transactions per year;
theoreticaly it should work - the only problem I see is: how to figure
out exact disk space used per transaction .
Convoluted ? Impossible ?
Please advise.
On 8/25/05, Christian Antognini <Christian.Antognini_at_trivadis.com> wrote:
> >-----Original Message-----
> >From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Thomas Day
> >Sent: 25 August 2005 19:03
> >To: Oracle-L
> >Subject: Re: Table growth - disk sizing
> >
> >Would you care to explain?
>
> Tom
>
> In a "regular" index the data is stored in ascending order (e.g. ..., 11,
12, 13, 14, 15, 16, ...). If you create an index on a column where the data
is inserted in "progression" (e.g. timestamp of the transaction or value
generated by a sequence), it's very likely, for concurrent transactions, to
modify the right-most leaf block. Of course this situation will result in
waits.
>
> Now, if you store the data in descending order (e.g. ..., 16, 15, 14, 13,
12, 11, ...) you will simply move the contention to the left-most leaf
block, i.e. it's not reduced.
>
> A possible solution for such a contention problem, it's to store the data
in reserve order (e.g. ..., 11, 21, 31, 41, 51, 61, ...). With this method
the transaction are well spread over "all" leaf blocks. Of course they are
drawbacks as well. One of the most important is the poor support of range
scans (the data is in the wrong order...).
>
> HTH
> Chris
>
>
> New Features Oracle Database 10g Release 2 seminars @ www.trivadis.com
> Italiano: Lugano (24-Nov)
> Français: Genève (17-Nov)
> Deutsch: Zürich (11-Oct), Hamburg (13-Oct), München (20-Oct), Basel
(25-Oct),
> Frankfurt (27-Oct), Bern (8-Nov), Düsseldorf (23-Nov), Stuttgart
(13-Dec)
> --
> http://www.freelists.org/webpage/oracle-l
>
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 26 2005 - 11:11:22 CDT
