Return-Path: <oracle-l-bounce@freelists.org>
X-Original-To: oracle-l@orafaq.com
Delivered-To: oracle-l@orafaq.com
Received: from puck1183.startdedicated.com (localhost [127.0.0.1])
 by puck1183.startdedicated.com (Postfix) with ESMTP id 5C46119614ED
 for <oracle-l@orafaq.com>; Thu,  2 Feb 2017 23:59:03 +0100 (CET)
Received: from turing.freelists.org (turing.freelists.org [206.53.239.180])
 by puck1183.startdedicated.com (Postfix) with ESMTPS
 for <oracle-l@orafaq.com>; Thu,  2 Feb 2017 23:59:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F0E2D6C6E6;
 Thu,  2 Feb 2017 17:59:01 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at turing.freelists.org
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VaxsNcg88iwD; Thu,  2 Feb 2017 17:59:01 -0500 (EST)
Received: from turing.freelists.org (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 56A276C6D3;
 Thu,  2 Feb 2017 17:58:49 -0500 (EST)
Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 02 Feb 2017 17:57:27 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 26ECF6C4CE
 for <oracle-l@freelists.org>; Thu,  2 Feb 2017 17:57:27 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id u9V1r4xaZ5Dz for <oracle-l@freelists.org>;
 Thu,  2 Feb 2017 17:57:27 -0500 (EST)
Received: from wp021.webpack.hosteurope.de (wp021.webpack.hosteurope.de [80.237.132.28])
 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 8448D68643
 for <oracle-l@freelists.org>; Thu,  2 Feb 2017 17:57:26 -0500 (EST)
Received: from app02.ox.hosteurope.de ([92.51.170.9]); authenticated
 by wp021.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128)
 id 1cZQJf-0007C3-ME; Thu, 02 Feb 2017 23:57:23 +0100
Date: Thu, 2 Feb 2017 23:57:23 +0100 (CET)
From: Stefan Koehler <contact@soocs.de>
To: "mark.powell2@hpe.com" <mark.powell2@hpe.com>, 
 jonathan@jlcomp.demon.co.uk, ORACLE-L <oracle-l@freelists.org>
Message-ID: <891515150.2109719.1486076243686.JavaMail.open-xchange@app02.ox.hosteurope.de>
In-Reply-To: <MMXP123MB0911FDE0FD7CB9C9D848E111A54C0@MMXP123MB0911.GBRP123.PROD.OUTLOOK.COM>
References: <CAPWdmV8XXRBr0dkmp39+c-t3RzuJFJmK7pKdwEzz+jdTGtk_VQ@mail.gmail.com>,<2118703869.2003798.1486061006447.JavaMail.open-xchange@app09.ox.hosteurope.de>,<DF4PR84MB020495B6122BF37F309FF02FCC4C0@DF4PR84MB0204.NAMPRD84.PROD.OUTLOOK.COM> <MMXP123MB0911FDE0FD7CB9C9D848E111A54C0@MMXP123MB0911.GBRP123.PROD.OUTLOOK.COM>
Subject: Re: UGA inside PGA, yes or no?
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Originating-Client: com.openexchange.ox.gui.dhtml
X-bounce-key: webpack.hosteurope.de;contact@soocs.de;1486076246;4cd482e5;
X-HE-SMSGID: 1cZQJf-0007C3-ME
X-archive-position: 67575
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: contact@soocs.de
Precedence: normal
Reply-To: contact@soocs.de
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <oracle-l-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@freelists.org?Subject=subscribe>
List-owner: <mailto:mark.bobak@proquest.com>
List-post: <mailto:oracle-l@freelists.org>
List-archive: <http://www.freelists.org/archives/oracle-l>
X-list: oracle-l

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: @OracleSK
Upcoming online seminar: http://tinyurl.com/17-06-13-Shared-Pool-Internals

> Jonathan Lewis <jonathan@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@freelists.org <oracle-l-bounce@freelists.org> on behalf of Powell, Mark <mark.powell2@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


