Re: fragmentation

This is only true on

1. Operating systems where you can guarantee the non-fragmentation of the datafile. (like VMS)
2. Non raid devices
3. When data is in sequence in the table and when the table is scanned in that order.

In all other cases keeping the tables contignious is not worth the effort.

Row chaining has a far greater impact on performace. But that can be solved by

1. Good database design ( blocksize, pctfree, ...)
2. Export import of the table affected.

Johnny Verhoeven
Adrian Shepherd wrote:
>
> I disagree with some of this,
>
> Extents allocated at the beginning of a data file, with the next extents
> allocated at the end of the datafile imply poor physical location and will
> cause seek times to increase. Poor seek times wont effect small databases or
> small insert/select operations, they will impact on full table scans and
> defeat logical i/o tuning such as clustering tables etc...
>
> Wim Coekaerts wrote in message <34C917CE.A3E_at_pacbell.net>...
> >One thing to note on fragmentation, it is always good practise to have
> >objects with the same extent size in the same tablespace, this way you
> >basically cannot have fragmentation... Unless you consider the fact that
> >you have multiple extents belonging to one object, fragmentation.
> >
> >now, tests have shown that the fact that a table has multiple extents
> >does not necessarily degrade performance...(hardly ever does) also, it
> >does not really matter whether all those extents are lined up or not, so
> >I would not worry too much about having more than 1 extent per object,
> >as long as you are not having problems allocating free extents because
> >of different size extents...
> >
> >hope this was clear, heh...
> >
> >Wim
Received on Mon Jan 26 1998 - 00:00:00 CST