Re: Extent size

In article <3846A6AF.1369BC92_at_pyramique.fr>,   Pierre STREEL <pstreel_at_pyramique.fr> wrote:
> Hi,
>
> I want to optimize my new database. I have 3 types of tables :
> - with 1.000.000 Rows (a lot of insertion in one time)
> - with 100.000 Rows (a lot of insertion in one time)
> - with 10.000 Rows
> - with 1.000 Rows
>
> I created 3 tablespaces for these data :
> - 128 K extent size for the first one
> - 96 K extent size for the second one
> - 64 K extent size for the third
> - 8 K extent size for the last
>
> and 2 tablespace for index, one for the big table and the other for
> small table
>
> Is it good to work like this, is it too much or too small ?
> What's the best solution for storage, in general ?
>
> Pierre

Looks to small to me.

Jonathan Lewis suggests that in a well managed database 20 extents per segment as a ball-park figure.
See http://www.jlcomp.demon.co.uk/extent.html

A large number of extents in a segment is not as important as it use to be, so there is no point getting too anxious about it. But given that question is asking for a guideline to aim at, rather than a rigid rule, then 20 seems reasonable to me.

So, given that you know how big each of your tables will be and that you have already allocated tables to tablespaces, you should be able to work out what extent size would tend to give around 20 extents per table or index. Obviously you want to pick a round number as your extent size (can you say a round number when your talking hex?), but you already seem to be doing that.

Ben

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Sat Dec 04 1999 - 02:47:48 CST