Re: How to "Defragment" Tablespaces ?

Brian-

Okay, finish the paragraph. Why is it a good idea? Is there a performance or scalability reason you can think of? Putting indexes and tables in the same tablespace is not "getting away" with anything. Presumably this is a scaled application and we are not really talking about discrete drives anyway... stripe and mirror everything.

There was this misplaced notion that started years ago, before raid systems became popular, that tables and corresponding indexes had these terrible concurrency conflicts and had to be kept apart. Well, it never was really true but the DBA myth persists. If, on the other hand, you manage objects by extent size and have a range of standardized tablespaces, I/O balancing becomes trivial. Set it up for manageability first, tune later.

Okay, your turn. Lets hear the reasoning.

• ricky

Brian Peasland wrote:

> > tablespaces that have heavy I/O contention. Never worry about indexes and
> > tables having to be on separate drives.
>
> Well, most of what you were saying was making perfectly good sense until
> this last sentence. While one *may* be able to get away with putting
> indexes and tables on the same drive, it is still a very good idea to
> separate them!!!!!!
>
> Just my 3.14159265 cents worth,
> Brian
>
> --
> ========================================
> Brian Peasland
> Raytheons Systems at
> USGS EROS Data Center
> These opinions are my own and do not
> necessarily reflect the opinions of my
> company!
> ========================================
Received on Thu Apr 05 2001 - 09:37:07 CDT