《信息系统行锁等待的成因分析及智能化解决方案》

“ 我们都知道数据库锁等待危害巨大，直接后果是业务失效或业务缓慢。《信息系统行锁等待的成因分析及智能化解决方案》一文是由极简智能CTO黄之怡（中关村中联企业金融投资创新促进会首席科学家）发布在《金融电子化》杂志上的一篇专业性文章，之前并没有以文字的形式进行分享，今天小编整理出图文的形式，以金融行业为例，通过对金融机构数据库行锁等待事件的系统研究，力求溯本求源，找到合理的应对方案，为同行提供参考和借鉴。”

《信息系统行锁等待的成因分析及智能化解决方案》

当前智慧金融发展的大背景是系统越来越多，业务复杂性呈指数增长，锁等待这一类软件问题会越来越高频的发生，但目前绝大多数金融机构缺乏有效的应对手段，这使得应对锁等待事件的紧迫性和必要性都尤为突出。由此造成金融机构业务受损的锁等待事件主要是行锁等待。在遭遇严重锁等待事件时，通常采用随机关闭业务进程或直接重启整个业务数据库系统的方式，但这两种处置方式都有严重的问题，一是都会造成业务的受损，二是这两种方式都会造成事后无法追溯问题的责任方，造成问题不断重复发生。

因此，非常有必要对金融机构数据库行锁等待事件进行系统研究，溯本求源，找到合理的应对方案。

01

—

锁等待对业务的危害

锁等待对业务的危害性可从以下三个维度来说明：

1.1造成的问题

较轻微的锁等待事件表现为业务缓慢，如造成办理大厅排长队；严重时则造 成相关业务完全失效；

1.2发生时间、问题目标物

经常发生在业务高峰时段的核心业务系统之上。

1.3高频发生

当前发生锁等待事件的不仅是业务繁忙的大、中型的金融机构，越来越多 的小型金融机构也开始频繁发生各种锁等待事件。

由上可见，锁等待事件对于业务的危害性非常严重，而当前智慧金融发展的大背景是系统越来越多，业务复杂性呈指数增长，这种背景下，如果不及时应对，锁等待这一类软件问题只会越来越高频的发生。但目前绝大多数金融机构缺乏有效的应对手段，这使得应对锁等待事件的紧迫性和必要性都尤为突出。

由于造成业务受损的锁等待事件主要是行锁等待，因此我们下文重点介绍行锁等待。

02

—

行锁等待的表现及成因

数据库中的锁是保障数据库访问顺序有序的一个必不可少的措施，而本文讨论的主体---行锁等待事件则是锁这一机制在系统运行过程中附带产生的一种负面表现。

行锁等待的典型场景，事务A要变更(Update)表1当中的某些行记录，事务A会在这些行记录之上放置行级排它锁，这个锁允许其他事务对这些行记录进行非一致读，但不允许任何其他事务对这些行进行DML（指对表中行的删除Delete、变更Update、插入Insert称为DML）修改操作，直到事务A结束释放该独占锁。此时，如果确有其他事务试图去修改这些被锁定的行，这些事务就会被迫等待事务A结束，才能执行自己的操作。

我们这里讨论的锁等待事件都是指那些严重超时的锁等待事件，正常运行时，每时每刻都在发生着锁的等待，只是正常的锁等待事件时间很短，绝大多数都是毫秒级别，而我们所讨论的对业务有重大影响的锁等待事件，至少达到了秒级，甚至几十分钟、几十小时。这些产生重大危害的行锁等待事件，主要有以下这样两种表现。

2.1第一种行锁：DML相关行锁

DML（即对数据的删除Delete、变更Update、插入Insert）语句会产生行锁，此时，如果有其他事务要修改同一行数据，就会产生锁等待。通常来说，DML语句如果锁定时间较长，通常有两个原因：

2.1.1DML语句需修改的数据量巨大，语句执行的时间自然比较久。

2.1.2DML语句在访问表时，可能缺少索引，产生了全表扫描，造成语句执行时间久。

我们用一个例子来说明这种情况：

UPDATE <表A>

SET FILE_CONTENT=:1, FILE_NAME=:2

WHERE ID=:3

如果 <表A>很大，有上百万行，如果ID作为查找条件的列没有建立索引，那么这条UPDATE语句运行时就会对<表A>进行全表扫描，时间就会很长，意味着行锁定的时间也会很长，如果这时有别的事务同样要修改<表A>上的相关行，就被迫产生了锁等待。这种情况产生的锁等待，我们可以用下图来进行说明。

《信息系统行锁等待的成因分析及智能化解决方案》

2.2第二种行锁：长事务相关行锁

调查显示，长事务才是造成大量锁等待的最常见情景，约占行锁的70%。在金融机构，它比第一种情景更加普遍也更不容易发现，所以危害也更大。我们用下图来分析一下典型的长事务造成的锁等待事件。

《信息系统行锁等待的成因分析及智能化解决方案》

第二种行锁等待与第一种相比，锁的持续时间长主要原因不是产生锁的DML语句执行时间长，而是整个事务执行时间较长，因为锁的释放是根据代码中的提交commit或回滚rollback标识来确定的。

这种锁的表现在系统中非常常见，比如我们往往在系统变慢的时候发现有锁等待事件，且发现正在阻塞其他会话的头锁进程正在跑一条不会产生行级锁的Select查询语句，甚至这条SQL语句访问的都不是被锁定的表。原因是锁是这条查询语句之前的其他语句产生的，而这条查询语句与产生锁的语句在同一事务当中，而当锁等待事件已经发生的时候，我们无论有实时查看的技术手段，只能看到事务当中正在执行的语句，所以，我们看到了这条Select查询语句。

03

—

行锁等待的常规处置方案

3.1DML相关行锁常规处置方案

对于必须在业务时段执行的DML语句，在表上增加索引或建立合适的数据分区以解决锁定时间过长的问题，如下图的描述：

《信息系统行锁等待的成因分析及智能化解决方案》

3.2长事务相关行锁常规处置方案

对于长事务造成的锁等待时间较长，第一选择是业务逻辑允许的情况下，在程序产生锁的语句后增加一次提交（commit）操作，以释放锁。

《信息系统行锁等待的成因分析及智能化解决方案》

3.3常规处置方式的局限性

上文提到了两种最主要的行锁等待事件的处置方案，但处置方案都是在问题已经发生，且确定了具体原因后的处置方法，没有从本源上解决行锁等待事件。

04

—

系统应对行锁等待事件

在应对锁等待事件方面，智慧金融的主要诉求是，如何能够尽量消除产生严重锁等待事件的各种潜在因素，以及在不能避免的锁等待事件发生后如何快速高效的进行处置。

4.1系统应对行锁等待思路

严重锁等待事件的发生是典型的多因素共同作用的结果，这个特征使得金融机构在应对锁等待这类事件时往往难以明确责任方，难以获得相关方到位的支持，但如果我们深究原因，可以发现锁等待事件的产生因素可以基本划定为三个主要因素，即软件性能质量、系统的可用资源量和特定数据库访问事件。软件性能质量的问题往往可以追溯到软件的研发和测试阶段，金融机构需要的是一个长期监控、持续分析优化的长期治理机制。我们将在其他文章中介绍这部分的细节。在本文中我们重点介绍对于锁等待事件的应急处置机制的建议。我们建议是：应主要借助智能化手段实现对锁等待事件的早期预警和快速自动诊断。

4.1.1关于早期预警

一方面，早期预警是金融机构业务健康运行的要求，锁等待事件是典型的“小恙不治酿大病”，刚开始可能只是一些性能指标上的异常，并未影响到业务运行，但当问题已经影响到业务时，往往诊断和解决也将变的成本高昂。

另一方面，技术上也允许实现早期预警。从技术角度来说，信息部门是完全可以做到早于业务部门发现问题的，因为锁等待事件的特征是先有异常征兆，逐渐发展，直到影响业务运行。这意味着如果我们能在早期注意到那些异常的征兆，并发出预警，就能让信息部门早于业务部门发现问题。

而我们当前的现状是，当锁等待事件已经严重影响业务时，业务部门才通知信息部门，即信息管理部门经常是晚于业务部门知道问题，这使的解决锁等待问题的黄金时间已经过去，金融机构要承受本可避免的业务受损才能解决问题。

4.1.2关于快速自动诊断

在锁等待事件已经发生的情况下，金融机构的诉求是要有手段尽快解决锁等待事件本身，以恢复业务的正常状态，这时最快的方法一定是借助智能化而不是依靠纯人工手段来实现对锁等待事件的瞬时溯源。

当前金融机构之所以难以具备早期预警和快速诊断锁等待的能力，是因为市场上比较缺少这类能够精确发现和自动溯源锁等待的工具软件。对于这类发生在应用层面的事件，传统的各类监控产品是一个盲区。

4.2智能化应对方案

通过研究，我们设计开发了一套高效且能实现早期预警、瞬时诊断、快速处置锁等待事件方法。其基本逻辑如下图

《信息系统行锁等待的成因分析及智能化解决方案》

4.2.1监控预警

要发现系统中正在发生的锁等待事件，一个比较通用的方法是通过监控与锁等待相关的性能计数器，一旦发现这些性能计数器出现异常时，迅速发出预警。比如，当锁等待的时间超过60秒时触发预警通知。

4.2.2溯源与查看

锁的溯源实际上可以用一种并不复杂的算法来实现，即递归算法，先去发现那些被迫锁等待的事务，再用算法递归查看是谁阻塞了它，阻塞它的事务本身又有没有被其他事务阻塞，这样一级级的递归回去，我们就能找到一次锁等待事件的头锁。

锁的查看也非常关键，我们现在已找到呈现锁等待事件的一套非常有效的技术：即用桑基图进行锁等待事件的全景呈现。桑基图最初是统计和反映河流流量的一种展示方式，来它呈现数据库锁等待的来龙去脉非常清楚，为信息管理者提供了一个观察锁等待事件的上帝视角。我们可以一眼看出，是谁产生了最初的头锁（图是最左侧的进程编号），以及整个锁等待事件的发展过程。

4.2.3应急处置

当我们能够在问题发生的早期发现问题，并拥有上帝视角来观察锁等待事件的时候，处置将变成一个简单的选择题，以下我们通过两个例子来进行这种智能化处置方式的说明。

以下两张图为某金融机构发生严重锁等待事件时的桑基图截图，例1：

《信息系统行锁等待的成因分析及智能化解决方案》

例1说明：这个例子展示的金融机构锁等待事务的复杂性，以及智能化手段的必要性，这是一个困扰某机构多年的锁等待事件，由于阻塞关系过去复杂，过去采用人工分析一直不能明确责任方。而事实上这个例子中的头锁进程2531，是一个非常不起眼的小程序，但经过多个不同业务程序之间的复杂传递，最终，2531的运行，总会导致整个核心业务-信用卡程序的缓慢甚至短时间失效。

拥有智能系统后的应急处置方案：迅速关闭或回滚造成阻塞的2531进程，如果业务逻辑允许，未来可以采用智能化手段来实现以下功能：即一旦这个小程序的运行又一次影响到核心业务，则可以通设置简单的关键字和阀值，用智能化手段自动进行处置。

05

—

总结与展望

以上提到的对行锁等待事件的处置方式和技术手段，已在多家金融机构进行了实践，目前的实践效果是：发生的严重锁等待事件均可在一分钟内被预警通知，并且在预警的同时，借助递归算法和桑基图已完成了锁等待事件的溯源分析，实时呈现锁等待事件的来龙去脉，为金融机构减少业务失效时间和实现对锁等待事件的早发现、早解决提供了成功的实践案例。

随着智慧金融建设的不断深入开展，应对锁等待这类软件相关问题，已经成为金融机构信息化建设当中的一项主要挑战之一，纵观当前金融机构经常遭遇的软件类问题，诸如锁等待、程序解析过量，索引缺失等，一方面，这些问题区别于硬件类问题的一大共同特征就是软件类问题，往往都有征兆、都有一个发展的过程，而不同于硬件的问题往往是瞬时发生的；另一方面，每一类软件问题有其复杂的一面，每一类软件问题的溯源算法都不尽相同，因此，当我们尝试用智能化手段应对锁等待这一类软件相关问题时，可以利用软件问题发生有前期征兆的这一特征，实现早期预警，利用算法库实现每一类软件问题的快速自动溯源。

能够高效的、智能化的应对软件类问题，使业务健康性得到基本保障，使信息管理的人力资源得以从不断的救火状态中脱身，是金融信息化管理从运维走向运营的基础，也是智慧金融升级的第一步.

参考文献

白新江, 李艳敏. 浅析SQL SERVER死锁产生的原因及解决[J]. 石油工业计算机应用, 2003, 011(004):34-36.

刘金梅. 银行核心业务系统的后台数据库优化措施分析[J]. 计算机光盘软件与应用, 2014(17):67-68.

朱明英. Oracle数据库中的锁机制研究[J]. 每周电脑报, 2006(22):52.

张卫华. 在客户端处理Oracle的数据行加锁问题[J]. 微电脑世界, 1999(47):85-87.

余钢, 朱莉, 张云睿. Oracle DML封锁等待原因分析和应用中的处理方法[J]. 电脑知识与技术, 2005, 000(012):42-43.

刘玉强. 基于ORACLE(OLTP)数据库性能优化方案的研究与实施[D]. 北京邮电大学.

——极简智能：精准预测关键业务系统运行风险并闪供解决方案——

地址：北京市海淀区大钟寺东路9号京仪科技大厦C座