UGA,PGA

tom认为UGA不包含 sort工作区，所以下面的图都是错误的

The UGA is, in effect, your session’s state. It is memory that your session must always be able to get to. The location of the UGA is wholly dependent on how you connected to Oracle. If you connected via a shared server, then the UGA must be stored in a memory structure that every shared server process has access to—and that would be the SGA. In this way, your session can use any one of the shared servers, since any one of them can read and write your session’s data. On the other hand, if you are using a dedicated server connection, this need for universal access to your session state goes away, and the UGA becomes virtually synonymous with the PGA; it will, in fact, be contained in the PGA of your dedicated server. When you look at the system statistics, you’ll find the UGA reported in the PGA in dedicated server mode (the PGA will be greater than or equal to the UGA memory used; the PGA memory size will include the UGA size as well).

 

So, the PGA contains process memory and may include the UGA. The other areas of PGA memory are generally used for in-memory sorting, bitmap merging, and hashing. It would be safe to say that, besides the UGA memory, these are the largest contributors by far to the PGA.

tom认为 sortarea

• 在dicidcate server的时候，是不在 uga里的,但是在 pga里但uga之外分配
• 在 shared server的时候，在uga里包含一部分，大小是（sort_area_retained_size），超出的部分在 pga里(sort_area_size-sort_area_retained_size)，

UGA is not PGA.

 

 

see the concepts guide or if you have access to my book Expert Oracle Database Architecture, I go through many concepts like this in detail.

 

 

1gb of data would likely not be loaded into the buffer cache all at once.

 

sort areas would be allocated in the PGA (not UGA, UGA might be used a bit if you are using shared server, but we are getting really detailed at that point) in general.

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4030213308432

it will allocate up to sort_area_retained_size in the UGA and the spill over into the "pure" PGA up to sort_area_size if the sort exceeds the sort_area_retained_size AND sort_area_size is greater then sort_area_retained_size.

 

the sort_area_retained_size parameter is often misunderstood. At a high level, this is what happens:

 

to do a sort, Oracle allocates chunks of memory up to a maximum of sort_area_size.

 

As each chunk is allocated -- Oracle checks to see if the sort area is less then the sort_area_retained_size.

 

If so, this chunk is allocated in memory that survives from call to call (in the UGA -- where ever the UGA might be -- in the pga or sga). This memory survives as long as needed (across many calls potentially to fetch rows and such)

 

If not, this chunk is allocated in the "pure pga" and freed at the end of the call. This memory does not survive across calls at all.

 

Sort area memory is not necessarily contigous memory -- hence bits of it could be in the SGA, some in the PGA -- it matters not to Oracle.

 

see also

</code> http://docs.oracle.com/docs/cd/B10501_01/server.920/a96536/ch1197.htm#1024241 <code>

 

1) What happens when the sort is completed,I mean where is the resultset(fetched rows) kept before sending it to the user process.According to me ,it is in UGA.

1) the sort workarea is kept in whole or part (the rest goes to TEMP on disk). The rows come from this 'retained' size.

 

In manual memory management, you used to set 

 

a) sort_area_size

b) sort_area_RETAINED_size

 

the amount of memory upto (a) would be allocated during the sort and upon completion - right before returning the data, the workarea would be shrunk down to (b) with any excess being written to disk. So, you could set (a) to 10mb and (b) to 1mb - we'd use 10mb to sort the data, shrink the workarea does to 1mb and use that as a buffer to return the data to the client through.

 

In automatic memory management, the server sets (a) and (b) as it likes.

 

所以下面的图都是错误的