enq: TS - contention事件说明

今天处理了客户数据库的enq: TS - contention等待事件，记一下处理思路

数据库发生错误

Wed Oct 23 13:47:46 BEIST 2013
ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMP

于是看了下awr

Event                Waits     Time(s)  Avg Wait(ms)  % Total Call Time    Wait Class
CPU time                        1,096                   63.7   
enq: TS - contention 797          367       461         21.4                 Other


这个一个2个节点的10205的rac

查了下资料：
enq: TS - contention 此事件在RAC中会更加常见，原因在于系统中临时表空间争用。
RAC里，所有节点共用同一个临时表空间，而temp extent pool一旦分配给某一个节点，其它节点将不可见；
一旦某个节点上分配的temp extent耗尽，则会发出cross instance call(CIC)向其它节点请求temp extent;
此时SMON就去回收所有节点的free temp extent，此过程会持有TS enq，CIC必须等待SMON完成对所有节点的free temp extent完成回收才会继续；

SMON每次向每个节点回收100个extents，目前每个extents设置为1M，4节点RAC一次回收400M；
但是如果操作的排序很大或者hash join数据非常多，SMON的处理速度可能跟不上应用请求速度，此时就会产生TS – contention；

另外，如果每个节点的temp extents分配不均，而大查询正好连接到分配比较少的节点上，情况会加重；

解决方法:
ALTER SESSION SET events'immediate trace name drop_segments level tablespace_number+1';
可以将此命令设置成crontab job，定时在每个节点执行；各个节点的free temp extents会及时的返回到temp pool


在单实例数据库中，试图drop temp tablespace的时候可能也会遇到类似问题
删除时候长时间等待enq: TS – contention，查看GV$lock找出阻塞会话为SMON进程，等待事件smon timer;
解决方法：
1、 查看temp表空间使用情况，杀掉session v$session,v$sort_usage
2、 设置drop segments事件，手工清理，ALTER SESSION SET events'immediate trace name drop_segments level tablespace_number+1';


总之：
根本的解决方法在于优化耗用多度临时表空间的sql语句
1、查看TEMP表空间的使用情况，找出使用TEMP表空间会话，看看是否可以杀掉：

select TABLESPACE_NAME, TOTAL_EXTENTS, USED_EXTENTS, FREE_EXTENTS
  from v$sort_segment;
 
SELECT se.username username,
       se.SID sid,
       se.serial# serial#,
       se.status status,
       se.sql_hash_value,
       se.prev_hash_value,
       se.machine machine,
       su.TABLESPACE tablespace,
       su.segtype,
       su.CONTENTS CONTENTS
FROM v$session se,
     v$sort_usage su
WHERE se.saddr=su.session_addr;

2、设置DROP_SEGMENTS事件,手工清理TEMP表空间：
alter session set events 'immediate trace name DROP_SEGMENTS level TS#+1';