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 est815perm01.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 est815perm02.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 est815 emp01.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 est815 emp02.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