admin管理员组

文章数量:1565786

有时候会在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：http://www.banping/2010/03/31/ges_potential_blocker/


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

转载于:http://blog.itpub/90618/viewspace-672010/

本文标签： potentialGESBlockertxresource

版权声明：本文标题：GES:Potential blocker on resource TX问题的处理 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/dianzi/1725280152a1016394.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。