Temporary Segments: What Happens When a Sort Occurs (文档 ID 102339.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.2.0.1 [Release 8.1.7 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 03-Nov-2014***

PURPOSE

This article describes what happens when a sort takes place, and how to optimize this process.

SCOPE

This document is intended for database administrators who want to review general information about temporary segments and temporary tablespaces.

DETAILS

Introduction.

Most SQL operations do not require data to be sorted. However, some operations do require sorting. Sorts can have a large impact on  performance.

- 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.

Memory Allocation.

Sorting requires space im memory. These memory areas are called sort areas. Every user session has their own sort area size. 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;

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 STATUS CONTENTS
----------------- --------- ---------
SYSTEM ONLINE PERMANENT
RBS ONLINE PERMANENT
USERS ONLINE PERMANENT
TEMP ONLINE TEMPORARY
INDX ONLINE PERMANENT
DRSYS ONLINE PERMANENT
PERM01 ONLINE PERMANENT
TEMP01 ONLINE TEMPORARY
8 rows selected.

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;

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.

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;

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 de-allocated 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 
dictionary-managed):

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;

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.

- Try and avoid sorts in index creation by loading rows into the table in ascending order of the index column. When the index is created, use the NOSORT option in the CREATE INDEX command.

- Remember that in parallel options, each query server will have its own sort_area_size allocated, which may lead to a memory shortage in other areas of the database.

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 database-users, 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.

PGA starting Oracle 9i

Oracle9i  and above provide an option to completely automate the management of PGA memory. 
Administrators merely need to specify the maximum amount of PGA memory available 
to an instance using a newly introduced initialization parameter 
PGA_AGGREGATE_TARGET. The database server automatically distributes this memory 
among various active queries in an intelligent manner so as to ensure maximum 
performance benefits and the most efficient utilization of memory. Furthermore, 
Oracle9i can adapt itself to changing workload thus utilizing resources efficiently 
regardless of the load on the system. The amount of the PGA memory available to an 
instance can be changed dynamically by altering the value of the 
PGA_AGGREGATE_TARGET parameter making it possible to add to and remove PGA memory 
from an active instance online. Since the database engine itself is better equipped 
to determine SQL execution memory requirements, database administrators should use 
this feature and not try to tune the PGA manually. This should translate to better 
throughput for large number of users on the system as well as improved response 
time for queries.

Oracle Database 11g supports various memory management methods listed below, which are chosen by initialization parameter settings. Oracle recommends that you enable the automatic memory management method.

1. Automatic Memory Management – For Both the SGA and Instance PGA 
2. Automatic Shared Memory Management – For the SGA 
3. Manual Shared Memory Management – For the SGA 
4. Automatic PGA Memory Management – For the Instance PGA 
5. Manual PGA Memory Management – For the Instance PGA