在我们日常运维过程中，经常会遇到两种类型的运维人员，一种是证明自己负责的业务组件框架没问题后就事不关己，高高挂起；另一种是，即便不是自己本职范围内的业务组件框架，或者自己负责的框架不是性能故障的根因，但只要能以自己的能力知识去帮助解决问题，就以一种不到黄河心不死的精神，全力协助上游或下游进行问题查找，直到业务恢复。其实，自己一亩三分地维护地再好，业务就是无法使用，站在全局的角度，有价值吗？所以，本着业务可用性，业务连续性的运维才是运维人该有的思想觉悟，也是运维人的最终价值之一。下面的案例介绍了如何基于数据库，以抽丝剥茧钻牛角尖精神，最终帮助业务侧定位到了业务中断问题的根因（业务逻辑问题）。
背 景
现场反馈某一项业务在大版本上线之后无法办理。开发人员首先怀疑是程序中的某条SQL执行较慢导致业务办理超时，于是先配合开发人员在数据库中抓取高耗SQL。在抓取高耗SQL的过程中，高耗SQL是没有抓到，却意外的抓到了一把“锁”（如下图），这把“锁”只有WAITER，却没有发现HOLDER。于是就有了接下来的故事。
在配合开发人员进行业务测试抓取高耗SQL的过程中，发现每一次该业务发起的时候，数据库中总会出现一条enq:TX - row lockcontention的等待事件。但奇怪的是这个TX锁中只有WAITER,并没有持有锁的HOLDER，于是将该等待事件中的SQL语句（如下图）发给开发侧确认。
开发侧也从程序错误日志中找到了该条SQL，由此可以初步判断导致业务处理无法闭环的原因应该是在执行该UPDATE语句时出现TX锁堵塞导致。但是究竟是谁持有了锁，导致UPDATE语句执行不下去呢？首先按照开发人员抓取的刚刚办理业务时传入的绑定变量手动执行了该UPDATE语句，看是否会有TX锁出现。结果如下图：
可以看到手动执行该UPDATE语句可以执行成功，没有出现TX锁。进一步排查该表是否有唯一约束，如果有唯一约束，程序在同一个事务里更新了两次同一记录也会产生TX锁，于是查看了该表上的索引（如下图）
可以发现该表的主键列在UPDATE语句中并没有修改，可以排除这一可能。那会不会是该表上存在TRIGGER，在更新的时候会触发某一条件导致出现TX锁呢？
查询该表的依赖对象发现只有FUNCTION和PROCEDURE,并没有TRIGGER,以上常见导致TX原因均被推翻，寻找HOLDER陷入了僵局。
寻找HOLDER陷入僵局，但问题还得接着排查，为了能更多的发现相关线索，请求开发侧多做几单业务，以便于测试过程的跟踪。平台这边也从之前的以表为中心来寻找问题转为以跟踪数据库对应的业务SESSION信息来定位问题，看看能否从SESSION中获取到更有价值的线索信息。
开发在做第一单测试业务时，我们将WAITER的相关SESSION做了PROCESSDUMP,然而从DUMP下来的TRACE文件中并没有发现有异常。于是又让开发做了第二单测试单据，第二单元测试的过程中，查询数据库相关视图发现被锁的表上同时有三个SESSION在访问，这引起了我们的注意。
WAITER明明是一个SESSION，为什么会有3个SESSION在访问呢，我们接着查看了这3个SESSION的信息（如下图）
除了WAITER的SESSION之外，另外两个会话均为INACTIVE状态，说明SQL已经执行完成。而其中为mainsrv程序发起的会话，主机名刚好和WAITERSESSION的主机名相同，这不免让人产生怀疑，这两个会话之间是否具有某种联系？
带着疑问，我们让开发人员继续做了2单业务进行测试，结果与我们推测一致。每次在业务发起的时候，被锁的表上均会有2个相同主机发起的两个不同程序的SESSION（如下图）
其中mainsrv程序的SESSION每次状态均为INACTIVE，而ordsrv程序的SESSION（即WAITERSESSION）每次状态均为ACTIVE。由此可以初步推断可能是由于mainsrv程序执行了某一SQL后可能导致之后的ordsrv程序执行的UPDATE语句堵塞。于是紧接着我们对mainsrv和ordsrv的SESSION做了PROCESSDUMP。此时，莫名有些兴奋，感觉HOLDER似乎离我们越来越近了，真相也离我们越来越近了。
在对mainsrv和ordsrv的SESSION做了PROCESSDUMP后，马上对两个TRACE文件进行了分析排查。果然在mainsrv程序的TRACE文件中发现了与ordsrv程序TRACE文件中几乎相同的SQL，原来mainsrv程序和ordsrv程序更新了相同的表，如图（上图为mainsrv程序的SQL，下图为ordsrv程序的SQL）
由此基本可以断定导致该业务办理超时的原因是:首先是mainsrv程序执行了UPDATE语句更新****_worklist表某一行数据，之后在同一个事务中跨服务调用了ordsrv程序，ordsrv程序也更新了****_worklist表同一行的数据。最终导致我们在数据库中查询到同时有2个SESSION访问了****_worklist表，mainsrv程序的SESSION状态为INACTIVE是mainsrv先执行完了UPDATE语句，ordsrv程序的SESSION状态为ACTIVE是由于被mainsrv执行的语句所堵塞，所以一直在等待锁的释放，直到程序超时。
将诊断结论发于开发侧核实，在开发侧排查代码后证实结论完全正确。至此，该问题根因找到，在开发侧发版整改业务逻辑后，问题彻底解决。本次分享到此结束，我们下次再见。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130219.html
摘要：基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构迁移演练及实施和试运行三个步骤。 在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述...
摘要：导读为数人云系列活动专题，本文是月日北京站线下活动当西方的遇上东方的互联网中京东金融王超老师的分享。王超京东金融企业高级目前在京东金融平台负责一个人左右的应用运维团队团队，也曾负责人人网团队。 导读：[GO SRE！] 为数人云SRE系列活动专题，本文是3月4日北京站线下活动当西方的SRE遇上东方的互联网中京东金融王超老师的分享。 他将从SRE，Devops， PE间的关系开始，介绍企...
摘要：导读为数人云系列活动专题，本文是月日北京站线下活动当西方的遇上东方的互联网中京东金融王超老师的分享。王超京东金融企业高级目前在京东金融平台负责一个人左右的应用运维团队团队，也曾负责人人网团队。 导读：[GO SRE！] 为数人云SRE系列活动专题，本文是3月4日北京站线下活动当西方的SRE遇上东方的互联网中京东金融王超老师的分享。 他将从SRE，Devops， PE间的关系开始，介绍企...
摘要：通过混合云方案，将前端服务部署在公有云上，利用公有云多分区和的优势使服务尽量靠近最终用户，后端仍部署在总部私有云中。通过这样的混合云跨云协同部署，可以大幅提升系统的服务能力和用户体验。近些年，随着云计算技术的逐渐普及，越来越多的企业选择了部署云计算方案，多数会选择私有云、公有云，混合云也越来越多的被提及和部署，这里简单聊聊混合云那些事儿。 什么是混合云？ 混合云不是简单的将几种云...
摘要：财年营收同比增长这是自财年第一季度以来，阿里云连续个季度保持超过的增长。联手运营商巩固资源优势阿里云的计算资源体量仍旧在飞快增长。财年营收同比增长121%!这是自2016财年第一季度以来，阿里云连续8个季度保持超过100%的增长。5月18日晚，阿里巴巴集团公布了2017财年(2016年4月1日-2017年3月31日)全年财报。与阿里云相关的数字是，财年营收规模达到66.63亿元人民币，同比上...
阅读 1032·2023-01-11 13:20
阅读 1309·2023-01-11 13:20
阅读 818·2023-01-11 13:20
阅读 1410·2023-01-11 13:20
阅读 3718·2023-01-11 13:20
阅读 2108·2023-01-11 13:20
阅读 1090·2023-01-11 13:20
阅读 3151·2023-01-11 13:20
