Re: db_block_buffer

> "Daniel A. Morgan" <dmorgan_at_exesolutions.com> wrote in message
> news:3A483B15.52588C51_at_exesolutions.com...
> > > Oracle 8.0.5 Solaris 2.6
> > > I"ve recently been told (by a database engineer and upper management)
> > > to increase our db's db_block_buffers from 15000 to 30000!
> > > I've tried kicking and screaming, tried to explain that you just don't
> > > randomly start doubling such parameters because the hit ratio is 75%.
> > > They seem to think it's going to solve all performance problems, but I
> > > know deep down
> > > it's just going to cause more issues.
> > >
> > > Just wanting to rant.
> > >
> > > TIA
> >
> > In the time it took you to rant you could have done it. And what would the
> > down-side have been? You change the parameter, you benchmark the system,
> > and you go on with your life. Personally, I agree with the others that the
> > change suggested is far too conservative.
> >
> > If all other things are equal (decent SQL with the right indexes), the
> > fastest way to improve the performance of an Oracle database is to grab
> > every bit of RAM on the system, and if you run out of RAM ... add more and
> > grab that too.
>
> Yes, but Daniel... Oracle DBAs are expected to show a little bit of
> *intelligence* about their use of resources, and piling on the RAM is
> fine -until someone asks you where best to pile it. And as we all (ought
> to) know, bunging extra RAM into the buffer cache if it's hit ratio is
> already around the 85-90% mark is just a *Waste of RAM*.
>
> A much better use of RAM "other things being equal" is to apply that RAM to
> the Library Cache.
>
> I'd be extremely impressed if you can merely by look at the number of data
> buffers and claim that that is 'too conservative' ...and be correct. Size
> isn't everything, Daniel, as you should have learnt by now. It's not what
> you've got, but how you hit it.
>
> Regards
> HJR
>
> >
> > Dan Morgan
> >

You are correct. But given the limited information available I'd do exactly as I suggested. Throw some more RAM at the problem and (as I said) benchmark the system.

The operative phrase was "benchmark the system". Just throwing resources at a problem is never the right answer.

Daniel A. Morgan Received on Wed Jan 24 2001 - 00:15:43 CST