Re: PGA Deallocation

From: Stefan Koehler <>
Date: Thu, 22 Jan 2015 10:31:29 +0100 (CET)
Message-ID: <>

Hi Zack,
yes, that quote is really old and it has changed since 9i. Quoting from Tom Kyte's book "Expert Oracle Database Architecture": The PGA is managed as a heap in 8i releases and is created via malloc()-ed memory. In 9i and above, new methods attach and release work areas as needed using operating system-specific memory allocation calls.  

Realfree heap management was introduced with Oracle 9i (hidden parameter "_use_realfree_heap"). You can also crosscheck your PGA usage by using view v$sesstat and you will usually see that "session pga memory" / "session pga memory max" and respectively "session uga memory" / "session uga memory max" differs - especially when using work areas for sorting, hashing, etc..  

I assume that you don't have switched from dedicated to shared servers along with the app change, right? If your app has changed, it might use some new Oracle functions which can cause this memory increase - or some functions got a PGA memory leak. The easiest way to find out is dumping the PGA and analyze the heap dump with Tanel Poder's heapdump_analyzer or use some views to a certain point.  

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher Homepage:
Twitter: _at_OracleSK  

> Jack van Zanen <> hat am 22. Januar 2015 um 04:58 geschrieben:
> Hi,
> Long time ago Steve Adams wrote
> "Although it is technically possible to do so, on most operating systems Oracle does not attempt to reduce the size of the process data heap
> segment and release that virtual memory back to the operating system. So from an OS pov, the virtual memory size of an oracle process remains at its
> high water mark"
> This was in relation to 8i.
> We are running AIX 6 and 11G and our sa's have noticed virtual memory usage going up.
> We have had a major app change few months back, so I am just wondering if this could be explained as the app is simply doing a lot more processing
> Jack van Zanen

Received on Thu Jan 22 2015 - 10:31:29 CET

Original text of this message