Large pool, MTS (shared server), Auto workarea_size_policy/pga_aggregate_target, 9i and 10g mixed together It's getting increasingly confusing when different factors are mixed. Here's my table of 8 cases that aids thinking. (SHA short for sort and hash areas; sort_area_retained_size is always in UGA in all cases, not shown here) Manual workarea size policy: dedicated MTS -------------------------- --------------------------------- 9i (1) SHA in UGA, UGA in PGA (2) SHA in UGA, UGA in large pool 10g (3) SHA in UGA (4) SHA in UGA, UGA in large pool Auto workarea size policy: dedicated MTS -------------------------- --------------------------------- 9i (5) SHA in UGA (6) SHA in UGA, UGA in large pool 10g (7) SHA in UGA (8) SHA in PGA (large pool not used) Auto workarea size policy works in cases (5), (7), (8), not (6). (8) is based on Jonathan Lewis's "Cost Based Optimizer", p.341: "In 10g, the shared server hash area has managed to migrate out of the UGA into the PGA, and so its size is dictated by the pga_aggregate_target." It's also verified by monitoring session PGA and instance large pool memory when the session is doing hashing. In case (8), we should expect shared pool latch contention to decrease because large pool won't be used. (Since 9i, large pool is managed by shared pool latches. There's no more large memory latch.) "UGA in large pool" means the bulk of UGA i.e. session memory part of it is in large pool. The small amount, fixed UGA, is still in shared pool. Ref: Note:62140.1. UGA is in PGA in Oracle8i and earlier, and 9i if using manual workarea size policy. In all other cases, because _use_realfree_heap is true by default, UGA is not inside PGA although it's private to the process. Ref: Tanel Poder, http://www.freelists.org/post/oracle-l/UGA-and-PGA-basic-question,1 http://www.freelists.org/post/oracle-l/Shrinking-PGA-of-snp-processes,6 Note:472527.1 (How And When To Change Default Page Size For Oracle?)