Comments on: Oracle memory troubleshooting, Part 3: Automatic top subheap dumping with heapdump

By: Playing with ORA-4030 error « Dion Cho – Oracle Performance Storyteller

Mon, 27 Jul 2009 07:34:43 +0000

[...] Heapdump on level 0×20000001 is described here. [...]

By: Blogroll Report 19/06/2009 – 26/06/2006 « Coskan’s Approach to Oracle

Fri, 26 Jun 2009 20:08:16 +0000

[...] Tanel Poder Oracle memory troubleshooting, Part 3: Automatic top subheap dumping with heapdump [...]

By: Memory Diagnostics – Part 2 « Miladin Modrakovic’s Blog: Oraclue

Memory Diagnostics – Part 2 « Miladin Modrakovic’s Blog: Oraclue — Thu, 25 Jun 2009 17:00:58 +0000

[...] http://blog.tanelpoder.com/2009/06/24/oracle-memory-troubleshooting-part-3-automatic-top-subheap-dum... [...]

By: Miladin

Miladin — Thu, 25 Jun 2009 16:45:29 +0000

This is just funny.I got my post on the same topic just ready to publish and did last check using google and found your post.

I found this event looking at Oracle bug Doc ID: 784804.1

Miladin

By: Tanel Poder

Tanel Poder — Thu, 25 Jun 2009 06:01:32 +0000

Yep, that’s a better understandable format for the parameter. Actually pretty much every numeric value in the event synax can be either in hex or decimal (I’ve shown one example with alter session here: http://blog.tanelpoder.com/2009/03/03/the-full-power-of-oracles-diagnostic-events-part-1-syntax-for-ksd-debug-event-handling/ )

For some reason it didnt seem to work with oradebug (but worked with alter session) when I tried – BUT now when I try again it works, so I must have done something wrong. Thanks for pointing this out to me!!!

By: Dion Cho

Dion Cho — Thu, 25 Jun 2009 01:34:35 +0000

Tanel, this is a little but very convenient unknown extension!

Anyway, instead of
oradebug dump heapdump 536870913
I would use
oradebug dump heapdump 0×20000001.

By: Tanel Poder

Tanel Poder — Wed, 24 Jun 2009 17:03:12 +0000

Hi Martin,

It’s a bit longer story – Oracle’s v$sesstat memory stats are not entirely correct in regard to what really happens with private memory allocation. They mimic the old-fashioned situation where UGA was physically INSIDE PGA heap, but its not like that anymore.

Nowadays, with realfree private memory management, PGA, UGA and Callheaps are completely separate top-level heaps (allocated separately from OS using mmap) and UGA is not physically inside PGA anymore.

A heapdump can easily confirm this, but in v$sesstat UGA is still reported inside PGA, so it’s probably impossible to create a situation where UGA is bigger than PGA in v$sesstat (unless you hit a bug or there’s some change which I’m not aware of)

By: Martin

Martin — Wed, 24 Jun 2009 16:57:18 +0000

Hello Tanel,
thank you for your post.
I’ve tried your way to reproduce an issue with very large UGA size (> 1 GB), it works fine.
However your testcase makes (on 10.2.0.4/AIX/dedicated server) both statistics ’session pga memory’ and ’session uga memory’ to show the large memory consumption.
Do you know a simple testcase which makes just ’session uga memory consumption’ grow?
Greetings from Austria,
Martin