Re: Looking for discussion on using large-ish PGA/SGA for PROD vs DEV/QA

From: David Fitzjarrell <>
Date: Wed, 29 Aug 2012 11:29:40 -0700 (PDT)
Message-ID: <>

I use Tanel Poder's sgastatx.sql script ( to report on the memory allocations and usage in the SGA subheaps; it can certainly help you decide if the SGA is oversized or not.  And, no, I don't believe it's an idiotic concept to check the SGA size.

David Fitzjarrell

From: "" <> To:
Sent: Wednesday, August 29, 2012 8:10 AM Subject: Looking for discussion on using large-ish PGA/SGA for PROD vs DEV/QA

As a few of you know I have taken a new job and one of the applications I'm responsible for has multiple dev and qa environments and one prod environment. ( RAC - 3 nodes in QA/Prod, 2 nodes in Dev)

We have a federal report that has started performing poorly in production and I have a QA environment with less volume where it returns reasonably well.

One of the challenges I'm having is that the SGA in Prod is 40 GB, and PGA = 5GB.  Dev GB/5GB, QA_at_GB/1 GB (PGA much different). (Challenges include coming up to speed at breakneck pace on environments, environment usage, statistics methodology (there isn't one), indexing methodology (there isn't one)...)

I think Jonathan Lewis or someone posted recently about large SGA sizes and PGA sizes - that having gobs of memory available doesn't *necessarily* mean automatically setting your databases up to use that large amount of memory (or perhaps I was dreaming).

I'm wondering if I should be much concerned about the SGA sizes currently and come back to them later, or if I should be looking at them in relation to query performance - that perhaps the SGAs are "oversized" or if that is an idiotic concept to begin with.  I'm going to research it further but wanted to throw that out there.

Chris Taylor

-- Received on Wed Aug 29 2012 - 13:29:40 CDT

Original text of this message