GES:Potential blocker on resource TX問題的處理

有時候會在Oracle alert日誌中看到如下資訊：

GES: Potential blocker (pid=348868) on resource TX-0013000E-0010D004;

這就是rac中的死鎖，一般Oracle會自己處理，有時候需要手工干預。要找到這個引起死鎖的session也很簡單，透過v$process和v$session檢視就能查到：

select * from v$session where paddr= (select addr from v$process where spid='348868')

可以根據這個session的情況來決定如何處理。比如這個session的program是oracle@p5b1 (J000)，這應該 是oracle自身的job，然後檢查dba_jobs_running，發現昨晚的一個job沒有跑完，而這個job阻塞了其他的session。

可以檢視v$session_wait檢視檢視該session的等待事件：

select * from v$session_wait where event<>'SQL*Net message from client'
and event<>'rdbms ipc message'

發現等待事件在db file sequential read和gc cr request間不斷切換，這在rac中是很常見的，說明這個job需要的很多block要從別的節點上作一致讀，而state是WAITED KNOWN TIME表示等待已經結束了。

那麼如何找到被阻塞的session是什麼呢？可以透過v$lock來檢視，block=1的是blocker，block=0的是waiter， 另外更直觀的做法是檢視DBA_WAITERS檢視，該檢視可以透過執行 $ORACLE_HOME/rdbms/admin/catblock.sql這個指令碼來建立。DBA_WAITERS裡的lock_id1和 lock_id2分別對應v$lock中的id1和id2，不同的lock有不同的定義， 比如TM的話，lock1就是object id。

如果嚴重影響了系統的執行，可以殺死引起死鎖的session：

alter system kill session '833,33751'

come from：