Doc ID: Note:102339.1
Subject:Temporary Segments: What Happens
When a Sort Occurs
Type: BULLETIN
Status: PUBLISHED
Content Type: TEXT/PLAIN
14-MARCreation
2000
Date:
Last Revision 31-MAR2003
Date:
Purpose.
This article describes what happens when a sort takes place, and how to optimize this process.
Scope & Application.
-------------------This document is intended for database administrators who want to review general information about
temporary segments and temporary tablespaces.
Temporary Segments: What Happens When a Sort Occurs
Contents.
1. Introduction.
2. Memory Allocation
3. User Defined.
4. Space Management in Tablespaces.
5. Temporary Segments in a Permanent Tablespace.
6. Temporary Segments in a Temporary Tablespace.
7. Guidelines.
8. Information about Temporary Segments.
9. Error Messages.
10. Related Documents.
1. Introduction.
Most SQL operations do not require data to be sorted. However, some operations do require sorting.
- Index creation.
The CREATE INDEX statement causes the server process (or processes if the index is being created in
parallel) to sort the index values before building the tree. After the sort a final index is built in the INDEX
tablespaces by using a temporary segment; once the index has been built completely, the segment type is
changed to index.
- ORDER BY or GROUP BY clauses of SELECT statements.
The server process must sort on the values in the ORDER BY or GROUP BY clauses.
- DISTINCT values of SELECT statements.
For the DISTINCT keyword, the sort has to eliminate duplicates.
- UNION, INTERSECT or MINUS operations.
Servers need to sort the tables they are working on to eliminate duplicates.
- Sort-Merge joins.
If no index is available, an equivalent-join request needs to perform full table scans and sort each row
source separately. After that, the sorted sources are merged together, combining each row from one
source with each matching row of the other source.
- Analyze command execution.
The Analyze command sorts the data to provide summarized information.
Besides these sort operations, there are other SQL operations, which also require temporary segments to
operate correctly. For example: CREATE PRIMARY KEY CONSTRAINT, ENABLE CONSTRAINT, and
CREATE TABLE.
The creation of a new table can start as a temporary segment if MINEXTENTS is larger than 1 or when
using the statement CREATE TABLE AS SELECT.
2. Memory Allocation.
The "init.ora" SORT_AREA_SIZE parameter defines the maximum size of real memory (in bytes) that will
be used by a single sort. Common settings of the SORT_AREA_SIZE parameter range between 64K and
256K for larger systems. The location in memory where this sort area is allocated, depends on the
configuration of the Server.
- Dedicated Server Configuration.
The sort area is allocated in the Program Global Area (PGA). Besides this sort area, the PGA also
contains session- information (e.g. user-privileges), cursor-status (of that session) and stack-space
(session-variables).
- Multi-threaded Server Configuration.
The sort area is allocated in the User Global Area (UGA). This UGA lies in the Shared Pool of the
System Global Area (SGA).
For each session there will be a moment in time when the first sort has to be performed. At that moment,
memory is allocated for performing that sort (sort area). The size of the sort area grows incrementally until
sufficient memory has been allocated to perform the sort or until it reaches the maximum as specified by
SORT_AREA_SIZE.
When a sort completes, the memory retained by that process for another sort is reduced to the value
specified by SORT_AREA_RETAINED_SIZE. This "init.ora" parameter defines the maximum size of real
memory (in bytes) that will be reserved for sorts after a previous sort has finished.
The difference between SORT_AREA_SIZE and SORT_AREA_RETAINED_SIZE is the memory, which is
freed after the sort. SORT_AREA_RETAINED_SIZE and SORT_AREA_SIZE default to the same value, so
all memory needed by previous sorts, will be available for next sort operations. When
the process as a wholeis terminated, the memory is returned to the operating system (in case of a
dedicated connection) or to the shared pool (in case of a shared connection).
Both "init.ora" parameters SORT_AREA_SIZE and SORT_AREA_RETAINED_SIZE can be changed
during the session. Example to set the sort memory for the current session to 100k:
ALTER SESSION
SET SORT_AREA_SIZE=102400
SORT_AREA_RETAINED_SIZE=102400;
To change these parameters for all new sessions, you can issue the
ALTER SYSTEM statement. Example to set the sort memory for all new sessions to 64k:
ALTER SYSTEM
SET SORT_AREA_SIZE=65536 DEFERRED
SORT_AREA_RETAINED_SIZE=65536 DEFERRED;
3. User Defined.
If the sort operation needs additional memory (above the value specified by the SORT_AREA_SIZE
parameter), then the sorted rows are written to disk to free up the sort area so that it can be re-used for
the remaining sort. This means that temporary segments are created. The sorted rows that are temporarily
written to disk, are stored in these temporary segments. The location where temporary segments are
created, depends on the settings for each user. To find out which tablespaces can be used by a user for
permanent and temporary segments, you could use the following query:
SELECT TABLESPACE_NAME, STATUS, CONTENTS
FROM dba_tablespaces;
TABLESPACE_NAME
----------------SYSTEM
RBS
USERS
TEMP
INDX
STATUS
--------ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
CONTENTS
--------PERMANENT
PERMANENT
PERMANENT
TEMPORARY
PERMANENT
DRSYS
PERM01
TEMP01
8 rows selected.
ONLINE
ONLINE
ONLINE
PERMANENT
PERMANENT
TEMPORARY
When a new user is created, the TEMPORARY TABLESPACE clause identifies the tablespace for the
user's temporary segments. Example:
CREATE USER hugo
IDENTIFIED by welcome
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE perm01
QUOTA 10M on users;
If you omit the TEMPORARY TABLESPACE clause, the temporary segments default to the SYSTEM
tablespace. For existing users, the temporary tablespace can also be changed. Example:
ALTER USER hugo
TEMPORARY TABLESPACE temp01;
4. Space Management in Tablespaces.
Tablespaces allocate space in extents. Tablespaces can use two different methods to keep track of their
free and used space.
- Dictionary-managed tablespace (extent management by the data dictionary).
For a tablespace that uses the data dictionary to manage its extents, Oracle updates the appropriate
tables in the data dictionary whenever an extent is allocated or freed for reuse. A tablespace that uses
the data dictionary to manage its extents has by default incremental extent sizes, which are determined
by the storage parameters INITIAL, NEXT, and PCTINCREASE. When an object is created in the
tablespace, its first extent is allocated with the INITIAL size.
When additional space is needed, the NEXT and PCTINCREASE parameters determine the sizes of new
extents. Because dictionary tables are part of the database, the space that they occupy is subject to the
same space management operations as all other data. This is the default method of space management
in a tablespace. It was the only method available in Oracle releases 8.0 and earlier.
- Locally-managed tablespace (extent management by the tablespace; Oracle8.1+).
A tablespace that manages its own extents, maintains a bitmap in each datafile to keep track of the free
or used status of blocks in that datafile.Each bit in the bitmap corresponds to a block or a group of blocks.
When an extent is allocated or freed for reuse, Oracle changes the bitmap values to show the new status
of the blocks. A tablespace that manages its extents locally can have either uniform extent sizes or
variable extent sizes that are determined automatically by the system. When you create the tablespace,
the UNIFORM or AUTOALLOCATE (system-managed) option specifies the type of allocation. The storage
parameters NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE are not
valid parameters for extents that are managed locally.
Locally-managed tablespaces have the following advantages over dictionary-managed tablespaces.
- Local management of extents avoids recursive space management operations, which can occur in
dictionary-managed tablespaces if consuming or releasing space in an extent results in another operation
that consumes or releases space in a rollback segment or data dictionary table.
- Local management of extents automatically tracks adjacent free space, eliminating the need to coalesce
free extents.
When you create a tablespace, you choose one of these methods of space management. It is not possible
to alter the method of space management later.
5. Temporary Segments in a Permanent Tablespace.
Temporary segments can be stored in any tablespace. However, there are some disadvantages when
storing temporary segments in a permanent tablespace:
- Every instance can have more than one temporary segment in the tablespace, because the segments
are created whenever needed on transaction-level;
- The tablespace can become very fragmented, because of the repetitive allocation and de-allocation of
temporary segments.
- The background process System Monitor (SMON) frees the temporary segments when the statement
has been completed; if a large number of sort segments has been created, then SMON may take some
time to drop them; this process automatically implies a loss of overall database performance.
After SMON has freed up the temporary segment, the space is released for use by other objects.
In general, you can use the following statement to create a permanent tablespace for temporary segments
with one datafile (in Oracle 8.1+ the tablespace will be dictionary-managed by default):
CREATE TABLESPACE perm01
DATAFILE '\oradata\test815\perm01.dbf' SIZE 10M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 100M
DEFAULT STORAGE (INITIAL 72K NEXT 72K PCTINCREASE 0);
In Oracle 8.1+ you can also create a locally-managed permanent tablespace for temporary segments (you
should use uniform extent-size):
CREATE TABLESPACE perm02
DATAFILE '\oradata\test815\perm02.dbf' SIZE 10M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 100M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 72K;
If we assume a default database block size of 8k, and that each bit in the map represents one extent
(72k), then each bit maps (72k / 8k =) 9 Oracle blocks.
A dictionary-managed permanent tablespace can be changed into a temporary tablespace. This is only
possible if no permanent objects exist in that tablespace. Example:
ALTER TABLESPACE perm01
TEMPORARY;
6. Temporary Segments in a Temporary Tablespace.
You can manage space for sort operations more efficiently by designating temporary tablespaces
exclusively for sorts (Oracle 7.3+). Doing so effectively eliminates serialization of space management
operations involved in the allocation and de-allocation of sort space. All operations that use sorts
(including joins, index builds, ordering and the computation of aggregates) benefit from temporary
tablespaces. The performance gains are significant in Oracle Parallel Server environments. In addition,
when you have multiple sorts that are too large to fit into memory, the temporary tablespaces can provide
performance improvements.
The temporary (sort) segment of a given temporary tablespace is created at the time of the first sort
operation, which has to write to disk to free up sort space in memory. The first disk sort (after instance
startup) creates a sort segment in the temporary tablespace.
Multiple transactions which need a sort on disk, can share the same sort segment, however, they cannot
share the same extent. The sort segment expands by allocating new extents. The sort extents are not deallocated while the instance is running, but are marked as free and can be re-used as required. Therefore,
the sort segment grows to a certain steady state. The Oracle server stores the information about the sort
segment in the Sort Extent Pool (SEP), a part of theSystem Global Area (SGA). Every statement that
needs to sort in the temporary tablespace checks this part of the SGA for free extents. Because the
extents do not have to be allocated and de-allocated after each operation, you will benefit an overall
database performance increase.
The background process SMON actually de-allocates the sort segment after the instance has been started
and the database has been opened. Thus, after the database has been opened, SMON may be seen to
consume large amounts of CPU as it first de-allocates the (extents from the) temporary segment, and after
that performs free space coalescing of the free extents created by the temporary segment cleanup. This
behavior will be exaggerated if the temporary tablespace, in which the sort segment resides, has
inappropriate (small) default NEXT storage parameters.
In general, you can use the following statement to create a temporary tablespace for temporary segments
with one datafile (in Oracle 8.1+, using this command implies that the tablespace can only be dictionarymanaged):
CREATE TABLESPACE temp01
DATAFILE '\oradata\test815\temp01.dbf' SIZE 10M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 100M
DEFAULT STORAGE (INITIAL 72K NEXT 72K PCTINCREASE 0)
TEMPORARY;
In Oracle 8.1+ you can also create a locally-managed temporary tablespace for temporary segments
(using this command implies that the tablespace can only be locally-managed with uniform extent-size):
CREATE TEMPORARY TABLESPACE temp02
TEMPFILE '\oradata\test815\temp02.dbf' SIZE 10M REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 100M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 72K;
If we assume a default database block size of 8k, and that each bit in the map represents one extent
(72k), then each bit maps (72k / 8k =) 9 Oracle blocks.
The temporary tablespace can be used for temporary (sort) segments only: no permanent schema objects
can reside in a temporary tablespace. A dictionary-managed temporary tablespace can be changed into a
permanent tablespace. Example:
ALTER TABLESPACE temp01
PERMANENT;
7. Guidelines.
The following guidelines can be used for temporary segments.
- Use a temporary tablespace to reduce the frequent allocation and de-allocation of temporary segments.
- Use one or more temporary tablespaces to minimize conflicts in data access.
- Stripe the temporary tablespaces over multiple disks. If the tablespaces are striped over 4 disks instead
of 2 disks, you can speed up sort operations twofold.
- Create tablespaces with different storage clauses and assign users to the temporary tablespace which
reflects their sort-specific usage.
- When specifying the default storage parameters, set INITIAL=NEXT, because a process always writes
data equal to SORT_AREA_SIZE to a temporary segment.
- Use the following formula for calculating the value for NEXT: (n*s + b) with
n = positive integer,
s = value of SORT_AREA_SIZE initialization parameter, and
b = value of DB_BLOCK_SIZE initialization parameter.
Doing so, you achieve there will be enough space in every extent to store header-block information and
the multiple sort run data.
Example: suppose the following parameters are declared in your
init.ora file:
DB_BLOCK_SIZE = 8192
SORT_AREA_SIZE = 65536
Then the value for INITAL (and NEXT) could be: 1 * 65636 + 8192 = 64k + 8k = 72k.
The above formula is only appropriate for dictionary managed temp tablespaces.
- When using a permanent tablespace, set PCTINCREASE to zero (so all extents have the same size)
and use MAXEXTENTS to define the maximum number of extents (a temporary tablespace defaults to
unlimited MAXEXTENTS).
- Be careful not to set the initial and next extent size too small for the temporary tablespace. See
[NOTE:61997.1]. If these are set too small then
it is possible to have thousands or tens of thousands temporary extents which can take oracle days to
clean up after shutdown abort and startup.
8. Information about Temporary Segments.
A query of the view v$sort_segment checks the temporary tablespaces
which contain sort segments. A brief explanation of some of the columns of this view:
extent_size : size of one extent, in number of Oracle blocks
total_extents: total number of extents in the segment (free or in use)
used_extents : total number of extents currently in use
free_extents : total number of extents currently marked as free
max_used_size: maximum number of extents ever needed by an operation (like a sort):
So you could use the query:
SELECT tablespace_name, extent_size, total_extents, used_extents,
free_extents, max_used_size
FROM v$sort_segment;
During a sort, you can see something like:
TABLESPACE_NA EXTENT_SIZ TOTAL_EXTE USED_EXTEN FREE_EXTEN MAX_USED_S
------------- ---------- ---------- ---------- ---------- ---------TEMP01
9
25
13
12
20
1 row selected.
After the sort, the information will be changed to something like:
TABLESPACE_NA EXTENT_SIZ TOTAL_EXTE USED_EXTEN FREE_EXTEN MAX_USED_S
------------- ---------- ---------- ---------- ---------- ---------TEMP01
9
25
0
25
20
1 row selected.
If you are interested in the amount of space in the temporary segments currently in use by the databaseusers, you can query the view v$sort_usage and the view v$session. The view v$sort_usage shows only
information during the sort. A brief explanation of some of the columns of this view:
extents: total number of extents currently in use by the user
blocks : total number of blocks currently in use by the user
So you could use the query:
SELECT s.username, u.tablespace, u.contents, u.extents, u.blocks
FROM v$session s, v$sort_usage u
WHERE s.saddr=u.session_addr;
During a sort, you can see something like shown below, meaning that
user HUGO is currently using (130 x 8k =) 1040k for a sort in the
tablespace TEMP01. Note the difference in extent-size: although each
extent was initially specified as 9 Oracle blocks, the actual extents
have 10 Oracle blocks each. This is default behavior: if the new
extent is 6 or more blocks, Oracle adds an extra block to the request to reduce internal fragmentation.
USERNAME TABLESPACE CONTENTS EXTENTS
BLOCKS
-------- ---------- --------- ---------- ---------HUGO
TEMP01
TEMPORARY
13
130
1 row selected.
After the sort, the information will be changed to something like:
USERNAME TABLESPACE CONTENTS EXTENTS
BLOCKS
-------- ---------- --------- ---------- ---------0 rows selected.
9. Error Messages.
Several error-message are related to temporary segments:
[NOTE:18248.1] ORA-00057 maximum number of temporary table locks exceeded
[NOTE:19027.1] ORA-01630 max # of extents reached in temp segment in tablespace <n
[NOTE:19047.1] ORA-01652 unable to extend temp segment by %s in tablespace %s
[NOTE:19235.1] ORA-01947 temporary tablespace already specified
[NOTE:19399.1] ORA-02156 invalid temporary tablespace identifier
[NOTE:21052.1] ORA-09904 sfotf: temporary file directory name is too long
10. Related Documents.
[NOTE:30918.1] Parameter Init.ora: SORT_AREA_SIZE
[NOTE:30815.1] Parameter Init.ora: SORT_AREA_RETAINED_SIZE
[NOTE:61997.1] SMON - Temporary Segment Cleanup and Free Space Coalescing
[NOTE:10640.1] Extent and Blocks Space Calculation and Usage in V7 Database
A67782-01 Oracle8i Concepts, Volume 1
A67795-01 Oracle8i SQL Reference, Volume 2
[NOTE:73439.1] Temporary Segment Handling in Temporary Tablespace.
[NOTE:1039341.6] Temporary Segments are not being released after sort.
[NOTE:160426.1] TEMPORARY Tablespaces : Tempfiles or Datafiles ?
[NOTE:1069041.6] How to Find Creator of a SORT or TEMPORARY SEGMENT or Users
Performing Sorts for Oracle8 and 9
Search Words:
=============
ORA-00057,ORA-01630,ORA-01652,ORA-01947,ORA-02156,ORA-09904