关于如何判断与解决deadlock的问题
2013-11-05 08:47
246 查看
当前应用时常会出现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"如下:
为了区别不同的类型,可以用锁类型,以及持有者和等待者的持有/等待模式,为每种类型创建一个标识。例如,上述图中展示了如下特征:
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现象。
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中如何判断数据表返回的结果集是否为空的问题解决
- 关于短信猫死机的问题程序要如何解决
- 关于解决DockManager如何停靠在其他布局控件问题
- 烦死了。。。看慕课网上的一个视频关于一个选择数据库的问题,,,,该如何解决呢?
- 【机器学习基础】机器学习算法的分类——关于如何选择机器学习算法和适用解决的问题
- iTextSharp应用中关于“Cannot access a closed Stream”问题的解决办法(附带提供如何在页面中显示PDF的流)
- 解决关于如何实现锁屏后继续播放音乐的问题
- 关于在eclipse里导入的项目出现 build.properties not exists 的问题如何解决
- 关于ogrebullet中如何判断两个物体何时碰撞的问题
- 关于linux动态链接共享库(如何解决应用程序跑不起来not found等问题)
- 关于如何用ISA解决内网多个网段上网的问题 推荐
- 关于如何判断程序和类库是Debug 还是 Release 的问题
- PHP关于如何解决表单POST传参数时,自动加转义字符的问题
- 关于OpenQuant试用软件的期限的延长问题...如何解决 OpenQuant 过期的问题
- iOS指南系列:如何解决奔溃问题-关于内存访问
- 关于Mysql中文乱码问题该如何解决(乱码问题完美解决方案)
- iOS开发工具-如何使用网络封包分析工具Charles,通过配置proxy对http、https、tcp、udp 等协议的请求响应过程交互信息进行分析、判断、解决我们移动开发中的遇到的各种实际问题。
- 关于mac OS X如何恢复网络出厂设置,基本可以解决mac各种网络链接问题。