Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Table growth - disk sizing

Re: Table growth - disk sizing

From: Ranko Mosic <ranko.mosic_at_gmail.com>
Date: Fri, 26 Aug 2005 12:00:28 -0400
Message-ID: <367369f10508260900bcf946e@mail.gmail.com>


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
Received on Fri Aug 26 2005 - 11:03:08 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US