Re: How to "Defragment" Tablespaces ?

So far the only thing I see is non-documented assumptions. If you are so sure about this, and even use words like 'DBA myths', why don't you just come up with *Proof*

Regards,

Sybrand Bakker, Oracle DBA

"Ricky Sanchez" <rsanchez_at_more.net> wrote in message news:3ACC8339.610789D1_at_more.net...
> 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 - 11:30:27 CDT