cancel
Showing results for 
Search instead for 
Did you mean: 

dbc_max_pct settings

SOLVED
Go to solution
Darrell Tschakert
Regular Advisor

dbc_max_pct settings

Hi,
We have some rx4640's with 24 Gig each of memory and two rx2620's with 8 Gig each of memory. These servers run oracle but are still configured such that the dbc_max_pct and dbc_min_pct are at 50 and 5 percent respectively. I understand that these values are high. One of the HP tuning manuals recommends 30 and 20 percent respectivly. From what I have read on this forum, it is not the percent value but the absolute value that should be considered in adjusting these parameters. First, is this true? Second, can anyone give me an absolute value recommendation for these two parameters. I will not poison the returns by listing the most commonly recommended absolute values mentioned on this forum.

Thanks,

Darrell Tschakert
I'll add a quote when I think of one.
9 REPLIES
Pete Randall
Outstanding Contributor

Re: dbc_max_pct settings

Standard advice is to aim for around 400Mb so adjust your percentages accordingly and monitor.


Pete

Pete
Jeff Schussele
Honored Contributor
Solution

Re: dbc_max_pct settings

Hi Darrel,

No - 20 & 30% are probably *still* too high.
Set the % such that you allocate a max of around 800MB - so that would be around 4% on the 24GB system & 10% on the 8GB system.
Your minimum can be probably 2%.

HTH,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
A. Clay Stephenson
Acclaimed Contributor

Re: dbc_max_pct settings

The value changes with the amount of memory in the system so that what makes sense for a box with limited memory doesn't make sense on a box with "lots" of memory. In any event, I will dump your boxes into the "lots" category although the 8GB boxes are not considered large these days.

You are going to find that the "sweet spot" lies somewhere in the 800-1600MB range on the newer versions of HP-UX. Very seldom, do cache sizes above 1600MB improve performance. If you are running Oracle, especially with raw devices, then you should make the SGA's large and reduce the UNIX buffer cache to ~800MB.

Eventhough the newer versions of HP-UX are good at ramping down the dynamic buffer cache, I still prefer to run static buffer caches by setting bufpages to a non-zero value (bufpages=409600 for 1600MB). This means that the buffer cache stays near the "sweet spot" even if you add much more meory to these boxes.
If it ain't broke, I can fix that.
Victor BERRIDGE
Honored Contributor

Re: dbc_max_pct settings

Hi,
Since you have alot of memory talking in % make s not much sence...
The issues you have with to much buffers is when it comes to sync... it can take quite some time if very large and there is alotto write down to disks, so I suppose it depends on your disks performance (FC ? on a SAN cache centric?...) but to be safe try to stay within a limit a 1 GB, I wouldnt give more than 500 MB to system with 8GB RAM...

All the best
Victor
Patrice Le Guyader
Respected Contributor

Re: dbc_max_pct settings

hi gents,

Isn't the size of this buffer cache as important as the options you used to mount your database ?
What I mean is that in performance course we speak about the well known "double buffers, so isn't it much intersting to have for exemple a buffer cache ,as defined like Victor says or up to 800 Mo according to Clay, but bypassing this buffer cache for oracle datafiles than having a big one of 1600Mo and a high level access on it and impacting the others FS using it ?

Any advise ?

Regards
Pat
Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
A. Clay Stephenson
Acclaimed Contributor

Re: dbc_max_pct settings

Surprisingly, my experience with HP-UX 11.11 and above performs best with that terrible "double-buffering". On 10.20 and 11.0 the situation was reversed (and in 32-bit land memory was precious) so that bypassing the buffer cache and reducing the size of the buffer cache helped. Under 10.20, I typically saw (and measured) about an ~18% gain by bypassing the buffer cache; 11.0 was about half that; at 11.11 the numbers reversed and 11.11 (& up) has improved buffer cache searches so that fully cooked files actualy performed best -- on my data. 11.11 (& up) also benefits from larger buffer caches than do earlier HP-UX versions so that 800MB-1600MB actually is better than 400-800MB that 11.0 was happy with.

At 11.23, you even have the Cluster File System (CFS) so that fully cooked files can be used with OracleRAC.
If it ain't broke, I can fix that.
Patrice Le Guyader
Respected Contributor

Re: dbc_max_pct settings

Thanks,

This famous performance course was provided by HP education on HP11i, so I'm also surprised but it's a very good think to have you explanation.

Thanks a lot.
Pat
Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
TwoProc
Honored Contributor

Re: dbc_max_pct settings

A. Clay your finding agrees with what research we had with the HP tuning center (good folks BTW). They found that unless your multiblock_read_count is at least 32, Oracle will not benefit from bypassing system buffering. Since mine is lower (and I didn't want to raise it, b/c the larger this number is, the greater the cost optimizer favors using full table scans), we DIDN'T bypass the system buffer cache for disks, in fact we increased both it and the buffer_cache inside of Oracle. This solution of increasing both buffer type factors really delivered the goods for us in performance. Its funny, because when Oracle Consulting was on site, I would repeatedly ask for analysis for a larger SGA for buffer_cache, and because we were at 97% hit ratio, they would follow conventional wisdom and say we were good enough. In fact, in regression testing, I would create test passes with increasing SGA, and they would insist that the gain was negligible, and would go back and lower it. HP came back, and analyzed it (like I asked), and found huge returns in GREATLY increasing the buffer_cache in the SGA, and with moderate increases in the system disk buffers, and removal of the "convosync=direction" option for the database file mounts. It was an interesting and enlightening analysis, that overwhelmingly proved that a lot of conventional wisdom re: buffer_caching in Oracle (re: size), and system cache in the OS was actually reversed from previous years' thinking. Basically their finding was that in high demand databases with high I/O (even after a year of very tough sql tuning), do everything you can to get off of disk, and use your caches - they almost always perform better than disk. Makes sense actually, but had contrary components that were different than what myself and many others were taught as being the conventional wisdom.
We are the people our parents warned us about --Jimmy Buffett
Darrell Tschakert
Regular Advisor

Re: dbc_max_pct settings

Thanks folks for all the help.

Darrell Tschakert
I'll add a quote when I think of one.