Re: Help: Settle an argument regarding EXTENTS

    Your DBA's right and he's wrong. For years Oracle's advice was to avoid throwing extents, and even to rebuild objects once they'd exceeded five extents. But just recently they've come around on this. In fact you can go to their metalink site and download a current white paper in which they recommend not worrying about extents (within limits - you probably don't want to have 10,000). What you do have to worry about is chained-rows. Your DBA can help there by using the proper storage parameters for your objects.

    A single extent of 60gig is probably not a good idea.     He probably has always built tables as he says, and that was standard thinking until maybe six months ago.

Van

Allan Kelly wrote in message ...
>We currently have a development project in progress. The whole application
>revolves around an Oracle 7.3.4 database. The users have told us that they
>anticipate having roughly 100 GB of data that will have to be archived off
>regularly after reaching this 100 GB high-water mark after 6 months of use.
>There are approximately 120 tables in the main schema. One of which, will
>hold approximately 57-60 GB of data when the high-water mark is reached and
>weekly archival begins (at the six month mark).
>
>My problem is: we have a contractor DBA hired to manage the database and
who
>stubbornly insists on allocating the complete storage size each table will
>occupy after six months in the INITIAL EXTENT. Example: for the main table
>described above, he wants to build the table with INITIAL set to 60 GB and
>NEXT set to 1.5 GB. He insists on building the other tables the same way.
>
>Knowing Oracle as I do, I find this more than a little disturbing. However,
>this DBA insists that "that's the way he's always built tables", with no
>other explanation or facts to back up his assertion.
>
>Trying to keep an open mind here, I am asking: Is there any benefit to this
>scheme he proposes? Let me hear your pro's and con's, please.
>
>Allan
>
>
>
Received on Tue Mar 30 1999 - 17:56:45 CST