enq: TS - contention

查看数据库的时候发现系统存在以下等待事件enq: TS – contention

此事件在RAC中会更加常见，原因在于系统中临时表空间争用。

RAC里，所有节点共用同一个临时表空间，而temp extent一旦分配给某一个节点，其它节点将不可见；

一旦某个节点上分配的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′

 

参考文档

http://www.tbdata.org/archives/203

http://www.dbaroad.me/archives/2009/07/drop_temp_wait_enq_ts.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15480802/viewspace-696905/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15480802/viewspace-696905/