关于如何判断与解决deadlock的问题
2013-11-04 18:01
381 查看
当前应用时常会出现deadlock的alert记录,关于如何判断与解决deadlock的问题,有一些介绍性的文章值得阅读。
How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1507093.1)
当Oracle检测到死锁后,会取消当前检测到死锁的SQL执行,并进行语句级回滚,以释放资源,不会阻塞所有活动。检测到死锁的session仍旧可用,其它的交易也处于active状态。如果重复执行这个session的该SQL,那么会再次检测到死锁。
当检测到死锁后,会产生一个trace文件,其中包含了“Deadlock Graph”(还有别的有用信息)。
有时trace中不包含这样的"Deadlock Graph"节信息,这种情况下,建议的操作是采集一些额外的诊断信息(例如10027事件),可参考:Document 1552194.1 ORA-00060 Deadlock Graph Not Matching any Examples: Suggested Next Steps。
"Deadlock Graph“的解释:
典型的一个"Deadlock Graph"如下:
![](https://img-blog.csdn.net/20131104180432343?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
为了区别不同的类型,可以用锁类型,以及持有者和等待者的持有/等待模式,为每种类型创建一个标识。例如,上述图中展示了如下特征:
1. Deadlock Graph包含超过1行的记录。
2. 所有的锁类型都是TX。
3. 持有者和等待者的锁模式都是X(排它锁,模式6)。
关注图中特殊的一些特征:
![](https://img-blog.csdn.net/20131104180426125?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
将会得到如下类型(典型的应用死锁):
TX X X
TX X X
注意:对于死锁类型识别的”关键标识“中最相关的部分就是锁类型和请求的模式。主要的类型如下表:
![](https://img-blog.csdn.net/20131104180530875?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
注意:如何判断和诊断不同类型的ORA-00060死锁的相关信息,可以参考:Document 1559695.1 How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace。
以上是最常见的类型与原因,极少有不同原因导致相同现象的情况。如果怀疑特定的非应用死锁类型或者有其它的deadlock graph,可以提交一个Service Request。
Oracle锁类型有如下几种:
0 - none
1 - null (NULL)
2 - Row Share, also called a subshare table lock (SS)
3 - Row eXclusive Table Lock, also called a subexclusive table lock (SX)
4 - Share Table Lock (S)
5 - Share Row-eXclusive, also called a share-subexclusive table lock (SSX)
6 - EXclusive (X)
注意:经常可以看到一种混合的deadlock graph:
![](https://img-blog.csdn.net/20131104180532906?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
此时是”Application deadlock“和”Missing Index on Foreign Key (FK) Constraint“的混合。建议先处理非”TX X X“的现象,因为这是一种常见的情况,不常见的FK/ITL/Bitmap可能是根源。
注意:trace文件中会包含不同的信息片段,其中有些是和问题相关的,有些则不是。例如,在”Rows Waited on“节,”dictionary objn“的值能用来明确相关的对象,但有时候,会提供毫不相关的信息。如果信息有用,那么就关注它,否则不要依赖于这些信息。
在当前应用中碰到的死锁问题是属于如下类型:
TX X X
TX X X
How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1559695.1)中介绍了关于”Signature:TX Lock Requesting Mode X (6)(TX X X)"这种类型的锁:
![](https://img-blog.csdn.net/20131104180636609?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
这种类型deadlock graph的问题有如下特征:
1. Deadlock Graph多于一行。
2. 至少有一行是”TX X X“,例如,锁类型是TX,锁的持有者模式是"X",不等待任何。等待者等待"X",不持有任何。
如果deadlock graph包含一些上述未提到的特征,那么先处理这些问题,因为这些问题可能是根源。
从”Rows waited on“节可以找到”dictionary objn“对应的Object ID。
![](https://img-blog.csdn.net/20131104180659515?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
也可以使用如下SQL查询Object ID对应的名称和类型:
![](https://img-blog.csdn.net/20131104180728421?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
trace文件也应该展示出两个session正在运行的SQL,还有应用的模块信息。在deadlock graph下面的第一部分就是从”Information on the OTHER waiting sessions:"到”End of information on OTHER waiting sessions."之间的部分,展示的是包含于这个deadlock的”Other“ session。
![](https://img-blog.csdn.net/20131104180727640?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
可以抽取如下信息:
![](https://img-blog.csdn.net/20131104180750921?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
![](https://img-blog.csdn.net/20131104180750921?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
在这节之后,就是检测到deadlock的session信息。以及SQL和调用栈(上面图中最下方),可以从PROCESS STATE节中得到更多关于操作系统进程的信息。
![](https://img-blog.csdn.net/20131104180822546?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
关于应用、SQL以及运行SQL的程序等等。
关于检测到deadlock的Oracle和操作系统信息可以在trace文件头中找到。
![](https://img-blog.csdn.net/20131104180852750?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvYmlzYWw=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
利用这些信息可以做什么?
通过上面的分析,可以得到如下信息:
1. deadlock中的object名称。
2. Oracle和操作系统名称。
3. 操作系统终端与程序细节。
4. 对于持有和等待session运行的SQL。
5. PL/SQL调用栈信息提供包的细节。
这些信息可以提供找到包含于deadlock的代码问题。判断为什么会出现deadlock,修改这些代码或者锁存储过程,以至于锁的顺序不会产生deadlock现象。
How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1507093.1)
当Oracle检测到死锁后,会取消当前检测到死锁的SQL执行,并进行语句级回滚,以释放资源,不会阻塞所有活动。检测到死锁的session仍旧可用,其它的交易也处于active状态。如果重复执行这个session的该SQL,那么会再次检测到死锁。
当检测到死锁后,会产生一个trace文件,其中包含了“Deadlock Graph”(还有别的有用信息)。
有时trace中不包含这样的"Deadlock Graph"节信息,这种情况下,建议的操作是采集一些额外的诊断信息(例如10027事件),可参考:Document 1552194.1 ORA-00060 Deadlock Graph Not Matching any Examples: Suggested Next Steps。
"Deadlock Graph“的解释:
典型的一个"Deadlock Graph"如下:
为了区别不同的类型,可以用锁类型,以及持有者和等待者的持有/等待模式,为每种类型创建一个标识。例如,上述图中展示了如下特征:
1. Deadlock Graph包含超过1行的记录。
2. 所有的锁类型都是TX。
3. 持有者和等待者的锁模式都是X(排它锁,模式6)。
关注图中特殊的一些特征:
将会得到如下类型(典型的应用死锁):
TX X X
TX X X
注意:对于死锁类型识别的”关键标识“中最相关的部分就是锁类型和请求的模式。主要的类型如下表:
注意:如何判断和诊断不同类型的ORA-00060死锁的相关信息,可以参考:Document 1559695.1 How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace。
以上是最常见的类型与原因,极少有不同原因导致相同现象的情况。如果怀疑特定的非应用死锁类型或者有其它的deadlock graph,可以提交一个Service Request。
Oracle锁类型有如下几种:
0 - none
1 - null (NULL)
2 - Row Share, also called a subshare table lock (SS)
3 - Row eXclusive Table Lock, also called a subexclusive table lock (SX)
4 - Share Table Lock (S)
5 - Share Row-eXclusive, also called a share-subexclusive table lock (SSX)
6 - EXclusive (X)
注意:经常可以看到一种混合的deadlock graph:
此时是”Application deadlock“和”Missing Index on Foreign Key (FK) Constraint“的混合。建议先处理非”TX X X“的现象,因为这是一种常见的情况,不常见的FK/ITL/Bitmap可能是根源。
注意:trace文件中会包含不同的信息片段,其中有些是和问题相关的,有些则不是。例如,在”Rows Waited on“节,”dictionary objn“的值能用来明确相关的对象,但有时候,会提供毫不相关的信息。如果信息有用,那么就关注它,否则不要依赖于这些信息。
在当前应用中碰到的死锁问题是属于如下类型:
TX X X
TX X X
How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1559695.1)中介绍了关于”Signature:TX Lock Requesting Mode X (6)(TX X X)"这种类型的锁:
这种类型deadlock graph的问题有如下特征:
1. Deadlock Graph多于一行。
2. 至少有一行是”TX X X“,例如,锁类型是TX,锁的持有者模式是"X",不等待任何。等待者等待"X",不持有任何。
如果deadlock graph包含一些上述未提到的特征,那么先处理这些问题,因为这些问题可能是根源。
从”Rows waited on“节可以找到”dictionary objn“对应的Object ID。
也可以使用如下SQL查询Object ID对应的名称和类型:
trace文件也应该展示出两个session正在运行的SQL,还有应用的模块信息。在deadlock graph下面的第一部分就是从”Information on the OTHER waiting sessions:"到”End of information on OTHER waiting sessions."之间的部分,展示的是包含于这个deadlock的”Other“ session。
可以抽取如下信息:
在这节之后,就是检测到deadlock的session信息。以及SQL和调用栈(上面图中最下方),可以从PROCESS STATE节中得到更多关于操作系统进程的信息。
关于应用、SQL以及运行SQL的程序等等。
关于检测到deadlock的Oracle和操作系统信息可以在trace文件头中找到。
利用这些信息可以做什么?
通过上面的分析,可以得到如下信息:
1. deadlock中的object名称。
2. Oracle和操作系统名称。
3. 操作系统终端与程序细节。
4. 对于持有和等待session运行的SQL。
5. PL/SQL调用栈信息提供包的细节。
这些信息可以提供找到包含于deadlock的代码问题。判断为什么会出现deadlock,修改这些代码或者锁存储过程,以至于锁的顺序不会产生deadlock现象。
相关文章推荐
- 关于如何判断与解决deadlock的问题
- 关于在Sqlite3中如何判断数据表返回的结果集是否为空的问题解决
- 关于如何判断程序和类库是Debug 还是 Release 的问题
- ADO.net 关于SqlParameter 遇到Like问题如何解决
- iOS指南系列:如何解决奔溃问题-关于内存访问续2
- 关于如何解决问题的一般性原则
- 看到的关于如何解决ArcEngine license 许可证的问题
- 关于如何解决问题的一般性原则
- 关于c语言中如何解决3n+1,溢出有关问题
- 关于如何高效的解决问题的探索
- 关于如何解决电脑连接上路由(宽带)但又上不了网的问题
- 关于如何解决谷歌Chrome浏览器空白页的问题
- 解决关于如何实现锁屏后继续播放音乐的问题
- 关于PS批处理存储JPG时总是要选JPG质量的问题,如何解决
- 关于共享单车的供电问题如何解决?
- 关于linux装载器(如何解决应用程序跑不起来not found等问题)
- 如何解决关于TableView里面cell随机显示的问题
- 【机器学习基础】机器学习算法的分类——关于如何选择机器学习算法和适用解决的问题
- 关于如何取消访问https时的提示:“此网站的安全证书存在问题”的解决方法
- 关于如何解决特定场景下WPF4.0中“XamlWriter.Save序列化限制”问题的一种思路