Re: Basic question on RAID array / Tablespace configuration.

Thanks Howard.

Unfortunately, Im not on a first name basis with 'Connor' so I dont know who he is. Do you have a link? :)

"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:af586l$pl9$1_at_lust.ihug.co.nz...
> Not sure, actually. Start with www.ixora.com.au, and follow any links that
> Steve has put up. Then visit www.oraperf.com, and read any papers that
Anjo
> or Cary have up there. Then read Jonathan Lewis' Practical 8i.
>
> I'd also recommend a visit to Connor's site, where he has a script that
lets
> you 'dial a hit ratio'. That's an essential: first time you show your
> colleagues that, they'll never look at hit ratios in quite the same way
> again.
>
> After that, start testing!
>
> Regards
> HJR
>
>
> "Ryan" <rgaffuri_at_cox.net> wrote in message
> news:jJlR8.70984$hF5.3034730_at_news2.east.cox.net...
> > Thanks Howard.
> >
> > Some I work with recommends Oracle Performance Tuning 101. What do you
> think
> > of this one? Which performance tuning book would you recommend?
> >
> > Thanks.
> >
> > "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
> > news:af385r$j9b$1_at_lust.ihug.co.nz...
> > > Niemic's book is about as bad as it gets.
> > >
> > > He's the guy who also rants on about hit ratios as if they were
somehow
> > > important.
> > >
> > > Take a look at google.com for the thread in this group called (I
think)
> > > "Oracle Myths". This is one of 'em for sure.
> > >
> > > Regards
> > > HJR
> > >
> > > "Ryan" <rgaffuri_at_cox.net> wrote in message
> > > news:N28R8.68325$hF5.2890600_at_news2.east.cox.net...
> > > > Really howard?
> > > >
> > > > I could have sworn that I read the the Oracle Performance tuning
book
> by
> > > > Richard Niemac and others that you should seperate your table
extents
> > from
> > > > your index extents on separate drives to avoid I/O problems?
> > > >
> > > > Did I read this wrong or is this just another bad book?
> > > >
> > > > "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
> > > > news:af21tj$700$1_at_lust.ihug.co.nz...
> > > > >
> > > > > "TR" <tman_at_tman.dnsalias.com> wrote in message
> > > > > news:6t%Q8.26123$XF6.3372526731_at_newssvr10.news.prodigy.com...
> > > > > > Have an approx 50 GB database (that is data+indexes) that will
be
> > used
> > > > for
> > > > > > aggregation queries and other OLAP type of stuff. E.g. write
> > > > performance
> > > > > > next to irrelevant, massive sequential reads from index and
> tables,
> > I
> > > > > guess
> > > > > > not a whole lot of probe-type random reads. Beware some of the
> > > queries
> > > > do
> > > > > > heavy writes to TEMP space.
> > > > > >
> > > > > > Hardware available is 8 80GB drives. Loss of data in the event
of
> a
> > > > drive
> > > > > > loss is of very little concern.
> > > > > >
> > > > > > Thoughts?:
> > > > > >
> > > > > > -> Stripe (RAID0) all 8 drives, then logically partition into
> Data,
> > > > Index,
> > > > > > Temp, etc.
> > > > > > -> Stripe (RAID0) 3 drives for Data, 3drives for Index, 2 for
> Temp.
> > > > E.g.
> > > > > > ensure that index and data are on separate physical devices.
> > > > >
> > > > >
> > > > > You've not been reading recent threads here, have you?
> > > > >
> > > > > There is precisely zero benefit in separating tables from their
> > indexes
> > > > for
> > > > > performance reasons. Both are segments. Just like Table A and
Table
> B
> > > are
> > > > > both segments. Separate A from B by all means, but unless you're
> > > > consistent,
> > > > > there's no point in separating a table from its index.
> > > > >
> > > > > Except for ease of management. Which I don't think you're even
going
> > to
> > > > > obtain in a RAID environment.
> > > > >
> > > > > TEMP, yes. Maybe. Rollback, yes, maybe. But not tables and
indexes.
> > > > >
> > > > > > -> Any better configurations?
> > > > > >
> > > > >
> > > > > I'd be going for 3 for data+indexes. 3 for rollback. 2 for temp.
> Just
> > my
> > > > > thoughts.
> > > > >
> > > > > Regards
> > > > > HJR
> > > > >
> > > > >
> > > > > > Thanks,
> > > > > > TR.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Sun Jun 23 2002 - 19:50:39 CDT