Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: So how big is your buffer cache ?

Re: So how big is your buffer cache ?

From: Tim Gorman <tim_at_sagelogix.com>
Date: Sat, 28 Aug 2004 11:28:03 -0600
Message-ID: <BD561CC3.1B3E5%tim@sagelogix.com>


Richard,

AWE only allows addressability to 16Gb, so I'm not sure where Mr Burleson calculated "working sets of 30-gig" or how he did so (or why), as that certainly won't fit into AWE-enabled SGAs. Hopefully, he's not simply summarizing the virtual-memory numbers for all the processes in a database instance, as that double-counts things like the text of the Oracle executable and the shared SGA?

The mention of the phrase "working sets" to me suggests sorting, which is an activity performed in the PGA, not the SGA. Since Mr Burleson's recent book "Creating a Self-Tuning Oracle Database" (first chapter, first page, first sentence, first paragraph) claims that the UNIX function call "malloc()" is used to create the SGA, I can see where his confusion between the SGA (created on UNIX with the "shmat()" and related system calls) and the PGA/UGA (created on UNIX using the "brk()" system call) exists. It is possible that the SGA could be utilized for sorting if one uses a regular tablespace as their temporary tablespace (i.e. tablespace not created as TEMPORARY), but I'm sure that this isn't under discussion.

As the AWE extension can only benefit the Buffer Cache (not anything else in the SGA) and certainly not the PGA, I'm really confused as to what the phrase "working sets" is intended to mean. No matter, anyway...

The claim of "ALWAYS with great results" would also benefit from better substantiation since the use of the parameter "use_indirect_data_buffers" (required for AWE) is also incompatible with all of the SGA management functionality of 9i, such as dynamically changing the sizes of the Buffer Cache, Shared Pool, Large Pool, Buffer Cache Advise, etc. I'm pretty sure I've seen articles by Mr Burleson touting these features in equally superlative terms? And the name of the parameter, mentioning "indirect data buffers" (which is a rare example of excellent naming by Oracle development :-) ), also provides insight into some of the performance overhead incurred by the use of the feature that the acronym "AWE" (i.e. address windowing extensions?) certainly doesn't convey.

So, right away, there are at least two caveats to the claim of "ALWAYS with great results": need to give up 9i SGA management functionality and need sufficient CPU resources to accommodate the additional processing of indirection when referencing buffers in the Buffer Cache using AWE.

Anyway, it appears that the original poster in question tuned a couple SQL statements and all his concerns and problems subsided, so the approach of "understand first, then fix" seems to have won a rare victory over the approach of feeding more resource to a resource-consumption problem as first principles instead of as a last resort.

Thanks!

-Tim

on 8/28/04 5:56 AM, Richard Foote at richard.foote_at_bigpond.com wrote:

> Hi All,
>
> In an interesting insight into how Don Burleson performs tuning at the
> c.d.o.s newsgroup
> (http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&th=73f606eef5e7e99f)
> . Don suggests he has "no problem throwing hardware at crappy code when the
> client doesn't want to tune it". He's also basically recommending using AWE
> and utilising all available RAM on 32bit windows, whether you need to or
> not. I mean, AWE has no disadvantages right ... :)
>
> However, he also makes the claim that "It's not uncommon to see working sets
> of frequently-referenced data of for than 30-gig for a large database. AWE
> is a great techniques for 32-bit Windows databases and I do it for dozens
> of databases every year, ALWAYS with great results."
>
> So my question to you all is how large are your largest buffer caches ? How
> many of you have a buffer cache that is 30G+ ? And on 32bit windows ?
>
> Love to know !!
>
> Cheers
>
> Richard
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------



Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Sat Aug 28 2004 - 12:22:10 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US