poor rcache after reducing dbc_max_pct

[Giles H Davidson]

Hi,
One of my Oracle database servers (11iv1) had dbc_max_pct set to 50% (with 37G Physical RAM), and as you might expect, there was frequently paging and swapping occuring.

We have since reduced this to 10% (still probably too high IMO), and although this has preventing any page outs, or swapping, the %rcache has gone from 100% down to anything from 5-85%.
This server does nothing except host several oracle databases.

We have a performance problem around the database which our DBA is investigating, but I am wondering if the reduction in dbc_max_pct from 50 to 10% could possible contribute to Oracle problems?

We could probably now increase the SGA and other oracle tunables now we have reduced dbc_max_pct as there is now plenty of free memory, but why such a bad read cache hit rate?

is this normal for a database server doing nothing but Oracle? (ie, Oracle is using its own cache so would that explain why %rcache is so low?

I have attached a text file with some sar -b and sar -d outputs... IO is nippy (<10ms), plenty of CPU time left, but some Oracle queries are taking an age to return. I'll leave that with the DBA for the minute, but need to understand why rcache hit ratio is so bad

[Hein van den Heuvel]

>> One of my Oracle database servers (11iv1) had dbc_max_pct set to 50% (with 37G Physical RAM), and as you might expect, there was frequently paging and swapping occurring.

I would only expect the if you used old HPUX version which did not do dbc min/max well enough and the SGA sizes had not been tuned in accordance to the available resources. Now I would not expect either from you!

What was DBC MIN percent? That is the amount of memory the system thinks it can rightfully use. MAX _should_ be a flexible upper boundary.

The buffer cache must have been helping Oracle a lot.

The most likely reason is that the buffer cache is a GLOBAL, 'social' pool. The individual SGAs are selfish. They only take care of themselves.
So if a system had 5 times 6 GB of SGA fro 5 databases, but 2 of those where not used much then the DBC can kick in an use the unused memory to augment the 'total' cache effectiveness for the busy databases. And when one of the slow databases kicks in, then some paging will re-balance matters.

With DBC reduced the system might have the memory pages, but is denied the right to use them flexibly.
Yeah you can bump the SGA's, but that is very static and per DB. The DBC works more flexible and potentially more performing.

Low DBC with perfectly tuned SGA + direct IO is perhaps ideal, but the price is high if you get it wrong. High DBC gives a nice sloppy buffer (sic) for less than perfect SGA tuning.

fwiw,
Hein van den Heuvel
HvdH Performance Consulting

[Steven E. Protter]

Shalom,

Good spread on the dbc_min_pct if you left it at 5%

Try adding some memory to the SGA for oracle, you just saved a bunch.

SEP

[Giles H Davidson]

dbc_min_pct = 5%

One thing that I have noticed is that a lot of posts regarding dbc_max_pct and Oracle also advise mounting with mincache=direct and convosync=direct. I currently have neither of these.

Would it be advisable to remount with these enabled or is this not part of the problem?

I have attached a screenshot of glance -m if that is worth anything.