Re: UGA inside PGA, yes or no?

Hey Mark,

> If the UGA in not part of the PGA then why does a dump of the PGA Heaps produce the UGA Heap as part of its output?

I agree with Jonathan. The dump code is very old and it dumps private heaps (top-level PGA, UGA and call heap) or recursive levels of it depending on the used level. In addition we also talk about some deep internals implementation here - mentioning/differing such details would confuse most people out there i guess. Just another example: You also say "memory for hash-aggregation is allocated in PGA" and not "memory for hash-aggregation is allocated in UGA and respectively in session heap -> kxs-heap-w -> QERGH hash-agg".

> What does physically stored in the PGA mean anyway in this context since the PGA as far as I know is not a single contiguous chunk of memory to
> begin with. Aren't the posted blocks just pointers and sizes of chunks of memory allocated from available memory on request?

Now we are getting really deep, but this is based on how heap memory is handled by the OS (or better said on top of the stack) - do not only think about the PGA memory allocation (chunks in heaps) from Oracle's point of view. Let's keep it very simple and look at the graphic in this article (http://www.linuxjournal.com/article/6390?page=0,0) and read the following explanation:

UNIX-based systems have two basic system calls that map in additional memory: * brk:brk() is a very simple system call. brk() simply moves that location forward or backward, to add or remove memory to or from the process. * mmap:mmap() is like brk() but is much more flexible. It can map memory in anywhere, not just at the end of the process.

Now if you think about the dynamically (de-)allocated heaps, sub-heaps, sub-sub-heaps (from Oracle's point of view) and map this to how heap memory is handled by the OS - i think it makes sense to source out various PGA allocations into other top-level heaps to be able to free it "on the fly" and give it back to the OS.

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher Website: http://www.soocs.de
Twitter: _at_OracleSK
Upcoming online seminar: http://tinyurl.com/17-06-13-Shared-Pool-Internals

> Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> hat am 2. Februar 2017 um 21:53 geschrieben:
>
> 1) Tradition
> 2) O/S is going outside my scope, but I think if the UGA is an arbitrarily growing subheap of the PGA then it's not safe to deallocate excess PGA
> memory because bits of the UGA might be inside the PGA chunk.
>
> Regards
> Jonathan Lewis
>
> ________________________________________
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Powell, Mark <mark.powell2_at_hpe.com>
> Sent: 02 February 2017 20:08:26
> To: ORACLE-L
> Subject: Re: UGA inside PGA, yes or no?
>
> Just some ramblings
>
> If the UGA in not part of the PGA then why does a dump of the PGA Heaps produce the UGA Heap as part of its output? What does physically stored in
> the PGA mean anyway in this context since the PGA as far as I know is not a single contiguous chunk of memory to begin with. Aren't the posted
> blocks just pointers and sizes of chunks of memory allocated from available memory on request? So isn't the UGA location (PGA vs SGA) just a logical
> location when not stored in the SGA? With dedicated server Oracle just takes the memory for the UGA out of the same pool as the PGA hence logically
> it is in the PGA.

--
http://www.freelists.org/webpage/oracle-l