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
Temporary Segments: What Happens When a Sort Occurs (文档 ID 102339.1)的更多相关文章
- MongoDB入门---文档查询之$type操作符&limit方法&skip方法&简单排序(sort)操作
上一篇文章呢,已经分享过了一部分查询操作了,这篇文章呢?就来继续分享哈.接下来呢我们直接看MongoDB中的$type操作符哈.它呢是基于BSON类型来检索集合中匹配的数据类型,并且返回结果,在Mon ...
- 段合并 segments merge 被删除的文档的删除时间
2.5 段合并 每个索引分为多个“写一次,读多次”的段 write once and read many times segments 建立索引时,一个段写入磁盘以后就不能更新:被删除的文档的信息存 ...
- Now trying to drop the old temporary tablespace, the session hangs.
1.描述 问题描述:删除临时表空间时,会话Hangs挂起 SQL> drop tablespace TEMP_B including contents and datafiles; 2.故障诊断 ...
- Oracle corrupt block(坏块) 详解
转自:http://blog.csdn.net/tianlesoftware/article/details/5024966 一. 坏块说明 1.1 相关链接 在看坏块之前,先看几个相关的链接,在后面 ...
- oracle_hc.sql
select event,count(1) from gv$session group by event order by 2;exec dbms_workload_repository.create ...
- ORA-00600: internal error code, arguments: [4194]
使用PlateSpin复制出来的一数据库服务器(Oracle 10g)在启动数据库实例时遇到"ORA-00600: internal error code, arguments: [4194 ...
- [MySQL Reference Manual] 8 优化
8.优化 8.优化 8.1 优化概述 8.2 优化SQL语句 8.2.1 优化SELECT语句 8.2.1.1 SELECT语句的速度 8.2.1.2 WHERE子句优化 8.2.1.3 Range优 ...
- ORA-1652: unable to extend temp segment by 128 in tablespace xxx Troubleshootin
当收到告警信息ORA-01652: unable to extend temp segment by 128 in tablespace xxxx 时,如何Troubleshooting ORA-16 ...
- ora-1652
###检查是否有temp 在使用 step 2: 检查是否有事务使用到temp,并且进行删除. SELECT vt.inst_id,vs.sid,vs.serial#,vs.username,vs.o ...
随机推荐
- C#.Net中的转义字符
当声明一个字符串变量时有一些字符是不能以平常的方式包含在变量中的.为了解决这个问题,C#提供了两种不同的方法. 第一种方法是使用’转义序列’.例如,我们想得到如下的字符串 “Hello World H ...
- net上传图片重命名
string FileName = File.FileName;//获取上传文件的名称 string Str = FileName.Split('.')[1];//获取上传文件的后缀 string N ...
- BI案例:某公司BI系统的九大主题分析
1.KPI分析 KPI分析按照管理层次和时间纬度对指标进行汇总统计及分析展示,以适应各级领导的管理需求.在某公司,KPI不仅只是一个数据展示,而且已经成为一个内部考核指标的监控平台.各级领导每天上班的 ...
- Mock框架
MoQ(基于.net3.5,c#3.0的mock框架)简单介绍 - 你听海是不是在笑 - 博客园 http://www.cnblogs.com/nuaalfm/archive/2009/11/25/1 ...
- ajax语法
js语言功能比较强大,但不能访问数据库 ajax来补充这一缺陷 特点:输出不用刷新页面,条件查询数据显示页面上一般不用它,因为需要造很多表格不如用嵌入php代码方式简单 ajax语法: $.ajax( ...
- 无需添加引用执行JS,发布无需带DLL、例子:QQMD5 QQGTK 13位时间戳 取随机数
javascriptDemo.rar 本人写POST经常会遇到用JS来加密的一些网站,然后又不想用C#重写.在百度和论坛里找的JS执行不是64位不支持就是要带个DLL神马的.很讨厌.然后自己就写了个不 ...
- [系统集成] Android 自动构建系统
一.简介 android app 自动构建服务器用于自动下载app代码.自动打包.发布,要建立这样的服务器,关键要解决以下几个问题: 1. android app 自动化打包android 的打包一般 ...
- 实现web数据同步的四种方式
http://www.admin10000.com/document/6067.html 实现web数据同步的四种方式 1.nfs实现web数据共享 2.rsync +inotify实现web数据同步 ...
- 黄聪:PHP5.6+7代码性能加速-开启Zend OPcache-优化CPU
说明 PHP 5.5+版本以上的,可以使用PHP自带的opcache开启性能加速(默认是关闭的).对于PHP 5.5以下版本的,需要使用APC加速,这里不说明,可以自行上网搜索PHP APC加速的方法 ...
- 黄聪:Wordpress、PHP使用POST数据过大导致MySQL server has gone away报错原因分析
错误原因: 当POST的数据超过 max_allowed_packet 就会报 MySQL server has gone away 的错误. 1.查看当前Mysql的 max_allowed_pac ...