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′

 

參考文件