Re: db file sequential read wait

"Brian Peasland" <dba_at_remove_spam.peasland.com> wrote in message news:3FB39326.6684D922_at_remove_spam.peasland.com...

> > Probably a size that didn't make dbwr work overtime to do a checkpoint...
> > I'd look at how many dbwriters this thing has. Async write
> > or no async write, a 1G buffer cache ain't gonna be
> > flushed easy. Regardless of it being excessive or not, which
> > is a different problem.
>
> access patterns? And that's the point I'm trying to make. You
> immediately assumed that I need to flush a 1GB buffer cache often. Maybe

I assumed nothing. I said "probably". That's not an assumption? :) Besides, I don't think I criticized anything: read the above again.

> 20TB in the next year). And 97%-99% of the data is static. So is a 1GB
> buffer cache too big in my case, or just plain ridiculous?

Dunno. I'd need to know what is the working set size for your buffers in your application. If you only ever have around 500Mb of buffers in use, then your buffers are twice the size they should be, regardless of whatever the size of your db. The two things are not related automagically.

> Does this
> clearly demonstrate that I don't understand how things work?

Not at all. Why is it that you are replying to me as if I was Sy? I'm not. He lives in Europe, I live in Australia.

> they'd be fixed. IMO, if one is going to say that a parameter value of
> XX is wrong, then one should be able to say what that correct value is.

I think I suggested what the right value should be. Without any other numbers, thats about as far as Í'll go. I don't think the OP asked for precise numbers either: rather, suggestions for things to look at. Exactly what I replied to, as an add-on to your post.

> Otherwise, it is just generalities and assumptions, all of which *could*
> end the DBA in a bad position.

Anyone that takes any advice from here on face value without testing first...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam