案例分享：通过LMD的TRACE文件分析TX死锁

我们的文章会在微信公众号“Oracle恢复实录”和博客网站“https://www.cnblogs.com/www-htz-pw/” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！ 由于博客中有大量代码，通过页面浏览效果更佳。

最近一直在折腾自己的工作电脑，大约已经有一个多月没有发文章了。在上个月去某客户现场交流完成后，感觉电脑有点小卡，就使用万能大发：重启操作系统。就这重启，悲剧的事就发生了，重启后进入系统时，一直报密码错误，那怕输入正确的密码也一样的报错。后续经公司IT技术部的同事反馈公司电脑有安全策略限制，要求每间隔90天须更改一次操作系统密码，如未更改在90天到期时，会自动锁定用户，并且无任何邮件提示密码过期。奇怪的是明明记得离上次密码修改不到60天，但为什么会出报密码错误。后续跟其它同事交流时，他们最近也遇到类似的问题，但是他们等待30分钟左右后再可以登录了，而我的电脑就一直提示密码错误。公司电脑开启了硬盘加密，通过自己重置密码，需要通过恢复密钥来重置系统用户密码。不巧的是，我电脑不知道什么原因，恢复密钥没有自动上传到公司服务器，管理后台上没有我的恢复密钥。还有更悲剧的是，我系统用户没有开启通过iCloud来重置密码功能，此时也无法通过iCloud来重置密码。目前常用重置密码的方法都无法正常使用，IT技术部同事想着通过后台下发上传恢复密钥的指令，但是后台提示我电脑一直处于离线状态，此方法也行不通。至此，已经宣布我电脑的死刑了，只能重装系统。之前因为公司合规性的限制，电脑里面没有做实时备份，这下导致所有的文件都丢失了，包括工作中的文件，也包括博客网站关闭后备份的博客文章及之前已经写好还没有发布的几篇文章。又因为我对keyboard maestro软件是强依赖关系，之前很多此软件的脚本和配置都没有做备份，所以导致MacOS重装信息后，自己常用的很多功能都无法使用，到目前都还未完全恢复到之前的状态。重要的事情说三遍，数据记得备份、备份、备份。

真的没有想到一个天天跟数据打交道的人，天天谈容灾的人，自己的电脑却因为无备份而丢失了数据。其实我们在日常工作中也尝尝遇到这些问题，虽然有些看试完美的容灾解决方案，但是当真要用的时候才发现无法使用，或者无法完全接替生产业务的负载，平时多想想我们的容灾方案是否真的能应多我们极端情况下的容灾需求。

回到今天分享的一个主题，Oracle数据库TX锁等待（enq: TX - row lock contention）等待事件的分析过程。这个案例来至于一位朋友，让帮忙分析一下LMD的trace文件中不断产生TX死锁的信息。前端应用也反馈业务执行insert语句时，当某列的值为空时，业务就会hang住，通过oratop可以看到有enq: TX - row lock contention等待事件，手动kill会话，并且业务通过前端应用通过增加判断列是否为空的限制来从应用程序上规避此文件。这是一个非常简单的等待事件，网上也有大量的来讲解此等待事件的分析方法。那为什么今天还要说这个等待事件呢？原因有如下两个：

• 1，因为之前我们分析TX等待事件都是从ASH或者V