故障说明

XX银行数据库二代支付系统业务，在12月13日晚22点出现插入数据卡顿的现象，插入数据的业务表为JHB_IBPS_TXN

故障描述

工程师分析在22点的数据库等待事件，发现有1000多条的library cache lock等待事件

通过分析22点的历史等待事件发现，所有的会话都被931、以及859的会话锁住，产生了library cache lock的等待事件

当一个session会话对SQL语句进行硬解析的时候，这个session就必须获得library cache lock ，此时另外一个session

会话就不能够访问或者更改这个SQL所引用的对象，因此产生了等待。

通过相关视图，获取到13日晚上22点产生等待以及锁源会话859的sql均为以下sql文本类型

SELECT BRNO, PKGNO FROM JHB_IBPS_TXN WHERE CORE_ID = '2022121383471428'

并且通过awr视图也能发现，有大量相同文本的sql在执行，并且每条都只执行一次

因为该条sql没有进行绑定变量，导致每次执行该sql，数据库都需要重新进行一次硬解析，每次硬解析都需要

申请library cache lock对服务器产生了比较大的资源浪费

通过相关视图发现，22点的发生卡顿的同时，931会话是数据库自身在进行自动统计信息收集，该job同样会

申请library cache lock。

本次故障是由于上述sql没有进行绑定变量，在执行时产生了大量的硬解析，并且数据库定时收集统计信息的

job任务在22点也开始了运行，两类事件都在不断申请library cache lock，导致互相堵死，产生大量的等待

记录，最后造成二代支付系统在22点出现插入卡顿的现象

1. 业务层面：

数据库内存在执行次数频繁的sql，是需要对其进行绑定变量处理的，对该类sql进行绑定变量

SELECT BRNO, PKGNO FROM JHB_IBPS_TXN WHERE CORE_ID = '2022121383471428'

2. 数据库层面：

数据库自动统计信息收集周一至周五，默认为22点开始收集4小时，周六周日默认为6点开始收集20小时。

自动收集统计信息不能指定收集对象，同样时间段不会再次发生一样的等待，不过保险起见可以修改自动

收集统计信息的开始时间与持续时间，避免与业务发生冲突。