The sort extent pool (SEP) is an instance wide SGA data structure used to manage the extents of sort segments within temporary contents tablespaces. Sort segment creation, extension, shrinking and deallocation are managed by SMON in response to sort segment request messages. Other processes wait on an equivalently named wait event for these operations. The allocation and freeing of extents within sort segments and queries against V$SORT_SEGMENT and V$TEMP_EXTENT_POOL are performed directly under the protection of the sort extent pool latch.

Sessions keep track of the extents that they have been allocated in a sort segment via sort segment handle state objects. These and all other state objects reside in the SGA so that they can be read by PMON when cleaning up after dead processes.

During a disk sort, sessions track the use of space within their sort segment extents for particular sort runs using a sort space map. The sort space map is a small part of the sort area. The major parts of the sort area are the sort/read buffers and the write buffers.

Sort areas are part of the cursor work heap for a cursor. The cursor work heap is part of the runtime memory of the private SQL area for a cursor. For DML statements that complete in a single call, the private SQL area is allocated in the CGA which is always a subheap of the PGA, even for calls from multi-threaded sessions. For SELECT statements, the private SQL area must be located in the UGA because it has to remain accessible to subsequent fetch calls.

For dedicated connections the UGA resides in the PGA. For multi-threaded connections the fixed UGA resides in the shared pool, and the variable part of the UGA (including private SQL areas) resides in the large pool if it exists, and otherwise in the shared pool.

I hope that clears up the confusion. There is so much that is wrong in those quotes that I'm not surprised that you were confused. You were no more confused than the author - only more aware of it!

The question has been omitted.