Re: So how big is your buffer cache ?
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 28 Aug 2004 11:28:03 -0600
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@xxxxxxxxxxx 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@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
