In this DocumentPurposeScope and ApplicationTemporary Segment Handling in Temporary TablespacePerformance TipsReferences

Applies to: Oracle Server - Enterprise Edition - Version: 7.3.0.0 to 11.2.0.2 - Release: 7.3.0 to 11.2Information in this document applies to any platform.Checked for relevance on 22-Apr-2008Checked for relevance on 19-Nov-2010 PurposeTo explain how temporary segments within a tablespace of type TEMPORARY are handled. Tablespaces of type TEMPORARY were introduced in Oracle release 7.3. This document is applicable to Oracle 7.3.x, 8.x. 9.x, 10g and to 11g provided tablespace is dictionary managed. Scope and ApplicationFor DBA's requiring further understanding of how temporary segments are handled within a temporary tablespace. Temporary Segment Handling in Temporary TablespaceIn RDBMS release 7.3, Oracle introduced the concept of a temporary tablespace. This tablespace would be used to hold temporary objects, like sort segments. For performance reasons, management of a tablespace that is defined as temporary was changed so that the allocated segments and extents would NOT be released and placed on the freelist, but would only be MARKED as free.For example, when a sort occurs, Oracle allocates as many extents as are required to do the sort. At the end of the sort, the extents are marked as free, but they are not deallocated. The single sort segment approach avoids the space management primitives: A single sort segment is allocated and shared by multiple sort operations for a given instance. Allocations and deallocations of space from this new sort segment will not require standard ST enqueue. The first sort operation on the instance creates the sort segment. Subsequent sort operation may grow the sort segment by adding new extents or allocate the existing extents out of this segment. The sort segment eventually grows to a stable state where no extents are allocated No storage space deallocation after a sort operation, but only changing the status of the extents in the sort segments.As part of this, a new data structure was created. It is called the Sort Extent Pool and is allocated out of the Shared Pool in the SGA. This structure contains a description of all of the active sort segments and their extents in the sort segment. Processes that require access to the sort segment are synchronized by a local latch called Sort Extent Pool latch. The Sort Extent Pool latch can be found in the V$LATCH and V$LATCHNAME views.

As mentioned, there is a new tablespace type called TEMPORARY. By default, all tablespaces are created as PERMANENT. Permanent tablespaces can hold objects of all types, including sort segments. Sort segments created in a PERMANENT tablespace still follow the old algorithm and are cleaned up/removed by SMON after usage. Temporary tablespaces can ONLY hold sort segments, no other objects can be, nor will be allowed to be created in the tablespace. There are two ways a tablespace can be identified as TEMPORARY:

1. With the CREATE TABLESPACE...TEMPORARY command2. Using ALTER TABLESPACE...TEMPORARY

See Oracle Database SQL Language Reference 11g Release 2 (11.2) manual for the correct syntax to use. The status of a tablespace can be determined from the CONTENTS column in the DBA_TABLESPACES and USER_TABLESPACES views.

To view information about sort segments, temporary or otherwise, there is a new dynamic performance view - V$SORT_SEGMENT. This view contains information about every sort segment created in the instance (describe the view for the list of column names, also see the Oracle Database Reference 11g Release 2 (11.2) manual).Performance TipsSort Segment ParametersSort segments take their storage parameters from the DEFAULT STORAGE (NEXT) clause of the tablespace in which they reside. All allocated extents are of a fixed size. The number of extents is unlimited.

Excessive Sort Latch WaitIf there is a lot of contention for the Sort Extent Pool latch, even in the stable state, you should increase the extent size by changing the NEXT value of the DEFAULT STORAGE clause of the temporary tablespace. If the wait is the result of too many concurrent sorts, you should increase the SORT_AREA_SIZE parameter so that more sorts stay in memory.

Excessive Extent Allocations/DeallocationsIf the ADDED_EXTENTS and the FREED_EXTENTS columns of the V$SORT_SEGMENTS table show excessive allocation/deallocation activity, you should consider adding more space to the corresponding tablespace. If the MAX_SORT_SIZE column of V$SORT_SEGMENTS indicates that large-size sorts occur, you should consider assigning a different temporary tablespace for these operations.

SGA Memory ThrashingBecause the Sort Extent Pool is allocated from the SGA, it may affect the behavior of other SGA caches and pools. The size of the pool is roughly proportional to the NUMBER of total extents of all the Sort Segments in the instance. Increasing the extent size will reduce, but may increase the temporary storage usage (the last extent used by each sort will be only partially filled). Each extent takes up about 20 bytes out of the Shared Pool for its Sort Extent Pool structure. ReferencesNOTE:160426.1 - TEMPORARY Tablespaces : Tempfiles or Datafiles ?NOTE:65973.1 - Temporary Tablespace, the Sort Extent Pool, and OPS