等待信息系统行锁等待的成因分析及应对策略

信息系统行锁等待的成因分析及应对策略

当前在大型金融机构的信息化建设与管理中各种金融业务系统频繁遭遇业务数据库的锁等待事件其直接后果是造成金融机构业务失效或业务缓慢在我们的研究中按照问题的具体技术原因分析 这类业务源端数据库端产生的锁等待事件所造成的业务受损事件已可排在前一、二的位置。

业务系统锁等待问题的大量增加是由于金融机构业务系统的快速增长 以及系统之间的数据交互使得业务复杂性随系统数量的增长呈指数增长 因此锁等待这一类纯粹的应用层问题越来越高频地发生 危害越来越大。而在当前 绝大多数金融机构对于锁等待这类发生在业务源端的应用类问题缺少高效的智能化应急处置机制。这使得应对锁等待事件的紧迫性和必要性都尤为突出。

行锁等待的表现及成因

数据库中的锁是保障数据被有序访问的一项必不可少的机制 而本文讨论的主体——锁等待事件则是锁这一机制在系统运行过程中附带产生的一种负面表现。 由于造成广大金融机构业务受损的锁等待事件主要是行锁等待本文通过对金融数据库行锁等待事件的系统研究 力求溯本求源找到合理的应对方案。

行锁等待的典型场景如下。事务A要变更Upda t e表当中的某些行记录事务A会在这些行记录之上放置行级排他锁 这个锁允许其他事务对这些行记录进行非一致读但不允许任何其他事务对这些行进行DML指对表中行的删除Delete、变更Update、插入Insert称为DML修改操作

1

直到事务A结束释放该独占锁。此时如果确有其他事务试图去修改这些被锁定的行这些事务就会被迫等待事务A结束 才能执行自己的操作。

我们这里讨论的锁等待事件都是指那些严重超时的锁等待事件正常运行时 每时每刻都在发生着锁的等待只是正常的锁等待事件时间很短 绝大多数都是毫秒级别而我们所讨论的对业务有明显影响的锁等待事件 通常达到了秒级甚至分钟或小时级。

我们统计了超过1000个行锁等待事件其中对相关业务造成了明显甚至严重负面影响的事件约有40个。这些产生重大危害的行锁等待事件主要有以下两种表现。

第一类行锁事件 DML语句的运行直接造成长时间的行锁等待。DML语句会产生行锁 因此在该DML语句运行时如果有其他事务要修改同一行数据就会产生行锁等待。通常来说 DML语句如果锁定时间较长通常有两个原因一是DML语句需修改的数据量巨大语句执行的时间自然比较久 二是DML语句在访问表时可能缺少索引产生了全表扫描造成语句执行时间久。

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

UPDATE<表A>

SETF ILE_CONTENT=:1 ,F ILE_NAME=:2

WHEREID=:3

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

2

图1 DML相关行锁

这一类行锁等待事件是最广为人知的但在实际分析研究中 我们发现对金融业务有明显影响的锁等待事件中只有约20%是这一类型。

第二类行锁事件长事务相关行锁。研究显示长事务才是造成大量锁等待的最常见情景约占有危害性行锁等待事件的80%。在金融机构 它比第一种情景更加普遍也更不容易发现所以危害也更大是本文认为需要重点研究应对的类型。我们用图2来分析一下典型的长事务造成的锁等待事件。

3

图2 长事务相关行锁

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

这种锁的表现在系统中非常常见 比如我们往往在系统变慢的时候发现有锁等待事件且发现正在阻塞其他会话的头锁进程正在跑一条不会产生行级锁的Select查询语句甚至这条SQL语句访问的都不是被锁定的表。这个现象非常普遍且让很多技术管理者困惑 究其原因 这时产

4

生的行锁是这条查询语句之前同一事务的其他语句产生的而当锁等待事件已经发生的时候 即使我们拥有实时查看的技术手段 也只能看到事务此时正在执行的语句所以我们看到了这条与被锁定表毫不相关的Select查询语句。

行锁等待的常规处置方法

方法一 DML相关行锁常规处置。对于必须在业务时段执行的DML语句在表上增加索引或建立合适的数据分区以解决锁定时间过长的问题如图3的描述。

图3 DML相关行锁常规处置示意图

方法二长事务相关行锁常规处置。对于长事务造成的锁等待时间较长 第一选择是业务逻辑允许的情况下在程序产生锁的语句后增加一次提交commit 操作 以释放锁。如图4所示。

5

图4 长事务相关行锁常规处置示意图

由此 我们看到在事后在问题根源被找到的情况下以上两类行锁等待事件的处置方式都是非常明确的。但现在困扰金融机构的是 能否在事前通过态势感知事中通过异常捕获就能更早的发现锁等待事件带来的业务受损风险从而做到在损失发生前规避风险或者减少风险损失。

用智能化手段应对行锁等待事件

在应对锁等待事件方面金融机构的主要诉求是事先能够尽量早的发现或消除产生严重锁等待事件的各种潜在因素在不可避免的锁等待事件发生时 能够尽快进行高效处置。

1.系统应对行锁等待思路。一部分锁等待事件与软件的代码和数据结构质量密切相关 这部分问题的程序质量原因往往可以追溯到软件的研发和测试阶段。但也有相关一

6

部分锁等待事件与业务主程序的质量无关且事先几乎不可预测。 比如那些因几个程序交互访问数据产生的锁等待事件。 因此对于锁等待这类纯应用层面的问题金融机构需要一个长期监控、持续分析优化的治理机制 也需要有一个对于锁等待事件的应急处置机制。

关于行锁等待事件的长期治理机制 主要与整个程序性能质量的持续管理有关 而不是只针对锁等待事件。本文重点介绍应对行锁等待事件的应急处置机制。这套应急处置机制是以保障业务健康和最小化故障时间为核心目标包括事前早期预警、事中智能化自动诊断、事后故障智能化自动恢复。

1早期预警。一方面锁等待事件是典型的“小恙不治酿大病”  刚开始可能只是一些性能指标上的异常并未影响到业务运行但当问题已经影响到业务时往往诊断和解决也将变得成本高昂。 另一方面技术上也允许实现早期预警。 因为锁等待事件的特征是先有异常征兆逐渐发展直到影响业务运行。这意味着如果能在早期注意到那些异常的征兆并发出预警就能让科技部门早于业务部门发现问题。而当前的信息化管理现状是一部分金融机构已能做到对于锁等待问题的预警和征兆发现。

2快速自动溯源。 当前金融机构往往借助工具预警锁等待事件依靠专业团队详细分析锁的根源 即分析和处置主要还是通过专业人工。这对于金融机构期望的尽快恢复业务、最小化故障时间的诉求来说是存在改进空间的 这时最快的方法是借助智能化工具而不是依靠纯人工手段来实现对锁等待事件的瞬时溯源。但这类能够在事前事中阶段自动分析诊断锁等待事件的工具在当前的智能运维市场上很少 相关工具都是实现发现问题 而不能对问题的来龙去脉进行详细的剖析所以对锁的自动诊断能力是金融机构需要重点去建设的。

7

3故障智能化自动恢复。在业务逻辑允许的情况下对一部分经常发生的且危害性已明确的锁等待事件实现自动处置或自动重置。 由于当前绝大多数金融机构尚不能实现对于行锁等待事件的自动诊断 而自动恢复是在自动诊断的基础上才能实现 因此这项能力目前也是大多数金融机构所欠缺的。

2.智能化应对方案。 以上提到的金融机构对锁等待事件处置的三项诉求 通过研究和实践 我们推荐一套方法以实现三项基本诉求的实际落地。

1事前监控征兆实现预警。在数据库层面锁等待事件产生的征兆通常是比较明显的。一个比较通用的方法是通过监控与锁等待相关的数据库性能计数器例如在Oracle数据库中可以监测appl icat ion类型等待的计数器一旦发现这一性能计数器出现异常增长时迅速发出预警。

2事中借助算法实现快速自动溯源。锁等待事件的溯源可以用并不复杂的递归算法来实现 即先通过监测等待计数器找到被迫等待的事务进程被阻塞者 再用算法递归查看是谁在阻塞它 阻塞它的事务本身是否有被其他事务阻塞 这样一级级地递归回去 我们就能找到一次锁等待事件的头锁阻塞者 。 另一方面 要把这一次锁等待事件的来龙去脉看清楚呈现技术的选择也非常关键我们推荐采用桑基图进行锁等待事件的全景呈现。这种呈现方式可以让我们以上帝视角一眼看出是谁产生了最初的头锁 以及整个锁等待事件的发展过程。

3事后先确定产生锁等待的事务对业务逻辑的影响才能确定可否进行自动恢复处置。锁等待事件自动处置的关键不是如何处置 而在于要先有清晰的界定锁等待事件的影响和危害 即在业务逻辑上是否进行阻塞者的关闭或重启 只要业务逻辑允许 则对应的处置即可实施。锁等

8

待的自动处置在技术实现上不存在难度 最通常的处置方式是哪一事务进程产生了锁等待 自动关闭这一进程即可。

随着智慧金融建设的不断深入开展应对锁等待这类软件相关问题 已成为金融机构信息化建设当中的一项重要挑战。 能够高效、智能化地应对软件类问题使业务健康性得到基本保障是金融信息化管理从运维走向运营的基础也是智慧金融升级的第一步。

9