In this Document
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 04-Dec-2012***
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
For DBA's requiring further understanding of how temporary segments are handled within a temporary tablespace.
DETAILS
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
Note that with Oracle 8i, another (locally managed) temporary tablespace was introduced that uses tempfiles and can be created like:
3. CREATE TEMPORARY TABLESPACE .. TEMPFILE
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.
Please, also refer to
Note 160426.1 - TEMPORARY Tablespaces : Tempfiles or Datafiles ?
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
|
