分類：版權聲明：本文爲博主原創文章，歡迎擴散，擴散請務必註明出處。
最近在rebuild index時提示unable to extend temp segment by 8192 in tablespace..的錯誤提示。這個是個比較常見的錯誤。索引在創建的時候需要使用到該用戶缺省的臨時表空間進行排序，以及在索引表空間生成臨時段。如果當前的索引表空間限制了自動擴展或者已經達到了數據文件的最大值，此錯誤提示便會出現。下面是具體的分析及其解決過程。
1、錯誤提示信息
2、關於ORA-1652錯誤
Error: ORA-1652
Text: unable to extend temp segment by %s in tablespace %s
------- -----------------------------------------------------------------------
Cause: Failed to allocate an extent for temp segment in tablespace.
Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more
files to the tablespace indicated or create the object in another
tablespace.
*** Important: The notes below are for experienced users - See Note:22080.1
Explanation:
This error is fairly self explanatory - we cannot get enough space for a temporary segment.
The size reported in the error message is the number of contiguous free Oracle blocks that cannot be found in the listed tablespace.
NOTE: A "temp segment" is not necessarily a SORT segment in a temporary tablespace.
It is also used for temporary situations while creating or dropping objects like tables and indexes in permanent tablespaces.
eg: When you perform a CREATE INDEX a TEMP segment is created to hold what will be the final permanent index data.
This TEMP segment is converted to a real INDEX segment in the dictionary at the end of the CREATE INDEX operation.
It remains a temp segment for the duration of the CREATE INDEX operation and so failures to extend
it report ORA-1652 rather than an INDEX related space error.
臨時段被使用的情形
A TEMPORARY segment may be from:
1) A SORT Used for a SELECT or for DML/DDL
2) CREATE INDEX The index create performs a SORT in the users default TEMP tablespace and ALSO uses a TEMP segment to build the final index in the INDEX tablespace.
Once the index build is complete the segment type is changed.
3) CREATE PK CONSTRAINT
4) ENABLE CONSTRAINT
5) CREATE TABLE New tables start out as TEMPORARY segments.
Eg: If MINEXTENTS is > 1 or you issue CREATE table as SELECT.
6) Accessing a GLOBAL TEMPORARY TABLE When you access a global temporary table a TEMP segment is instantiated to hold the temporary data.
3、TROUBLESHOOTING ORA-01652(Reference Doc ID 1267351.1)
#下面是無法擴展臨時段的2種情形
EXAMPLE 1:
Temporary tablespace TEMP is being used and is 50gb in size (a recommended minimum for 11g)
TIME 1 : Session 1 starts a long running query
TIME 2 : Session 2 starts a query and at this point in time Session 1 has consumed 48gb of TEMP's free space
TIME 3 : Session 1 and Session 2 receive an ORA-1652 because the tablespace has exhausted of of its free space
Both sessions fail .. and all temp space used by the sessions are freed (the segments used are marked FREE for reuse)
TIME 4 : SMON cleans up the temporary segments used by Session 1 and Session 2 (deallocates the storage)
TIME 5 : Queries are run against the views V$SORTSEG_USAGE or V$TEMSEG_USAGE and V$SORT_SEGMENT ... and it is found that no space is being used (this is normal)
EXAMPLE 2:
Permanent tablespace INDEX_TBS is being used and has 20gb of space free #此時無法擴展臨時表空間的問題當屬第2種情形
TIME 1 : Session 1 begins a CREATE INDEX command with the index stored in INDEX_TBS
TIME 2 : Session 1 exhausts all of the free space in INDEX_TBS as a result the CREATE INDEX abends
TIME 3 : SMON cleans up the temporary segments that were used to attempt to create the index
TIME 4 : Queries are run against the views V$SORTSEG_USAGE or V$TEMSEG_USAGE ... and it is found that the INDEX_TBS has no space used (this is normal)
#下面是Solution部分
First it is important to forget what is known about past behavior of the instance as the current tablespace size is insufficient to handle the demand by current sessions
There are three recommended methods of supplying sufficient storage space to meet the needs of current sessions by increasing the size of your temporary tablespace
1) Set one or more of the tempfiles|datafiles for the tablespace to AUTOEXTEND with MAXSIZE set ... so that you do not exhaust all available disk volume space
(discuss this with a System Administrator)
After a month or so of having this setting ... AUTOEXTEND can be disabled .. as it is likely that the system has found its true high watermark for temporary segment usage
(This is the most recommended method as it allows the database instance to find its own high watermark)
2) Monitor the temporary segment usage via queries like
SELECT sum(blocks)*<block size of the temporary tablespace>
FROM v$tempseg_usage
WHERE tablespace = '<name of the temporary tablespace>';
and resize one or more of the tempfiles|datafiles for the tablespace as the tablespace becomes close to exhausted
3) Add a tempfile|datafile to the temporary tablespace with the problem and monitor usage as described in #2
Another good idea is to monitor temporary tablespace usage over time to determine what queries are consuming the temporary space space
For example: How Can Temporary Segment Usage Be Monitored Over Time? (Doc ID 364417.1)
This note was written to monitor temporary tablespaces .. but may be able to be modified to also monitor permanent tablespaces
4、本案例故障解決方案