Re: Extent sizes

In article <2p0snc$cil@maicgn.SoftwareEngineering>, ar@mai.de (Achim Reiners) writes: |> |> I would like to have a better feeling about the performance impact |> of the definition of extent sizes (first and next) for tables. |> |> In our production database ( Online 5.01 ) we have already tables with |> about 50 extents. tbcheck already gives a warning at 8 extents. |> |> Are there any experiences or guidelines of configuring the first and |> next extent size the best way? As a rule of thumb, the best configuration is size the initial extent such that you are able to do the initial load into the first extent, and size the next extent such that all activity over the next two years will fit in the next 7 extents. Calculate size of initial load ==> first extent Calculate size of data for the next two years and divide by 7 ==> next extent. |> |> How big can the performance degradation be if configured in a bad way ? |> ( access is n times slower ? Which n ) Too many variables, depends on type and frequency of access, size of table, etc. I've seen it vary from little impact on small, infrequently used tables up to 4-5 times slower on large ( > 1 gigabyte ) tables. Extent size is very important. Do not go over 8 extents. |> |> |> Is it possible to change these for the system tables as well? These |> tables were the first ones exceeding the warning level of 8 extents! I know there is an answer to this one, but I don't remember, anyone else help? DCT