Introduction: In the alert log to check the database, the database was found reported ORA-1652: unable to extend temp segment of error, the record of the entire process:
1, check the size of the current database table space, the script follows
select file_name,file_id,bytes/1024/1024,status,autoextensible TABLESPACE_NAME from DBA_TEMP_FILES;
2, the current database table space temp 32GB has been set up, under normal circumstances, if the temporary table space around 20GB enough (as needed according to Table magnitude criteria database)
Based on knowledge of the system, the initial judge this growth is clearly abnormal behavior;
(If the space is too small, then the table can be increased by the statement: ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 10240M AUTOEXTEND OFF;)
3, because every time the error is in the morning, it is impossible not to sleep has been tracking the use of temporary table space, but fortunately, you can use Oracle Diagnostics event tracking ORA-1652 events, events affecting the performance of the diagnostic system is very small, because only when this error occurs, the system will write information to the alert log;
Level tracking is divided into three levels:
- Enable the database for tracking the session level: ALTER SESSION SET EVENTS '1652 trace name errorstack';
- Enabling the database at the system level tracking: ALTER SYSTEM SET EVENTS '1652 trace name errorstack';
- This parameter is written to the spfile file: the ALTER the SYSTEM the SET EVENT = '1652 errorstack the trace name' SCOPE = SPFILE;
(For more on setting the parameters, but also put together a document, you can search in the blog)
Close corresponding script as follows:
- ALTER SESSION SET EVENTS '1652 trace name context off';
- ALTER SYSTEM SET EVENTS '1652 trace name context off';
- ALTER SYSTEM RESET EVENT SCOPE = SPFILE SID = '*';
4, when the next day, and she has given a detailed error message is as follows:
ORA-1652: unable to extend temp segment by 128 in tablespace TEMP
Errors in file '/u01/app/oracle/diag/rdbms/orcl/ORCL/trace/orcl_m000_15204728.trc:
Open the corresponding error information is as follows:
| *** 2015-02-04 00:12:07.836 |
After the above track, finally we know the cause of the temporary table space to run out the culprit, the next statement is analyzed;
5. Also note that the above situation is not necessarily out of the track is the main reason may be the last straw that breaks the camel, because in front of a sentence with a 95% TEMP table space, followed by another a statement with a 6% TEMP table space, this time the system will record the second statement. But the real reason is that the front piece using 95% TEMP statement of table space;
Under normal circumstances, you can monitor the occupancy of the contents of the table space inside, but also to analyze the causes of the problem, the script is as follows:
| SELECT S.sid || ',' || S.serial# sid_serial, S.username, T.blocks * TBS.block_size / 1024 / 1024 mb_used, T.tablespace, T.sqladdr address, Q.hash_value, Q.sql_text FROM v$sort_usage T, v$session S, v$sqlarea Q, dba_tablespaces TBS WHERE T.session_addr = S.saddr AND T.sqladdr = Q.address(+) AND T.tablespace = TBS.tablespace_name ORDER BY S.sid;  |
Can be found in SID / SERIAL SESSION 5/1273 is consumed a lot of table space temp;
6, the above provides a solution to the whole problem, we recommend that you try the next hands-on, experimental steps are as follows:
a, create a large table;
b, created the index;
c, diagnostic event tracking open ORA-1652 events;
d, to create the index again;
e, check alarm logs;
Summary: Learning is a process of constant experimentation and summary, the process of recording each time begin to solve the problem is always fun;
......................................................................................................................................................................………………………………………
Author: JOHN, a listed company DBA, spare time to focus on technical management of the database, from a management perspective to the use of technology.
ORACLE technology blog: Hunter notes ORACLE database technology group: 367 875 324 (please note ORACLE management)