You are on page 1of 3

In this Document

Purpose
Scope and Application
Temporary Segment Handling in Temporary Tablespace
Performance Tips
References

Applies to:
Oracle Server - Enterprise Edition - Version: 7.3.0.0 to 11.2.0.2 - Release: 7.3.0 to 11.2
Information in this document applies to any platform.
Checked for relevance on 22-Apr-2008
Checked for relevance on 19-Nov-2010

Purpose
To 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 Application


For DBA's requiring further understanding of how temporary segments are handled within a
temporary tablespace.

Temporary Segment Handling in Temporary Tablespace


In 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 command
2. 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 Tips
Sort Segment Parameters
Sort 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 Wait
If 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/Deallocations


If 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 Thrashing
Because 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.

References
NOTE:160426.1 - TEMPORARY Tablespaces : Tempfiles or Datafiles ?
NOTE:65973.1 - Temporary Tablespace, the Sort Extent Pool, and OPS