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

Home -> Community -> Usenet -> c.d.o.server -> Re: Large initial extent after import

Re: Large initial extent after import

From: Jurij Modic <jmodic_at_src.si>
Date: Sat, 14 Nov 1998 21:59:25 GMT
Message-ID: <364df88a.42118263@news.siol.net>


On Sat, 14 Nov 1998 18:07:27 GMT, pantah_at_commonsense.a2000.nl (Jan Dolman) wrote:

>I've been thinking about this problem some more but I still don't
>_understand_ the implications. Apparently, the number of blocks will
>be the same no matter what size of extent you choose (i.e. you can
>create 11.000 extents of 6 blocks or 6 extents of 11.000 blocks). So
>you basically choose to:
>a) keep the number of blocks (per extent) down, or
>b) keep the number of extents down.
>
>Can anybody _explain_ which option is better, I mean, it is pretty
>easy to understand that chained rows will have impact on performance,
>but I still don't see any reason to choose either option (apart from
>the performance gain Neil noticed, well, can anybody explain that
>one?).

Multiple extents per table can *theoreticaly* have impact only when you are performing table scans, ie when you are not using indexes. However, if the extent sizes are chosen correctly in regard to DB_BLOCK_SIZE and DB_FILE_MULTIBLOCK_READ_COUNT init parameters, then you can neglect the impact of multiple extents on performance even when performing table scans.

If you want to read more technical in-depth explanation of this fact take a look at *excelent* paper "Avoiding A Database Reorganization" by Craig A. Schallahamer
(http://www.europa.com/~orapub/papers/pmain.htm).

>Thanks
>--
>Jan
>pantah_at_commonsense.a2000.nl
>(replace "commonsense" by "speed" to reply)

HTH, Jurij Modic <jmodic_at_src.si>
Certified Oracle7 DBA (OCP)



The above opinions are mine and do not represent any official standpoints of my employer Received on Sat Nov 14 1998 - 15:59:25 CST

Original text of this message

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