Re: db file sequential read - again

  • From: jherrick@xxxxxxx
  • To: Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>
  • Date: Tue, 13 Mar 2007 09:40:12 -0600

Quoting Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>:


What is your rationale of putting "hot indexes" into their own pool?
What are you trying to accomplish with this?


Thanks for the info Wolfgang.

I guess I was just thinking that if high-usage index blocks were in their own
pool they wouldn't be aged out of the main (DEFAULT) pool. If they were
in the pool then they would not have to be read from disk. I guess this
would have to be tempered with how often the indexes are modified.

In typing this response though I see the error in my thinking....if they are
hot enough then they shouldn't be aged out of the default pool. So segregation
is not going to help.

Would simply caching them in the default pool accomplish the same thing then?
Or simply increasing the size of the main pool? I have 16Gb of memory and the
buffer cache is currently taking up 6Gb.

BTW...haven't had a chance to look at STATSPACK yet. TIMED_STATISTICS was set
to false when I arrived last week and scheduling a bounce is problematic. So
I'm looking at 'live waits' right now until I can gather some more useful
info.

Cheers

JH

--
//www.freelists.org/webpage/oracle-l


Other related posts: