核心生产上一个严重且有趣的Bug(二)

继《核心生产上一个严重且有趣的Bug(一)》所描述的问题,昨日我们进行了第二次实际生产Bug测试工作:

本次测试分为三个阶段:

(1)阶段一:基于Space Serach Cache是PGA管理的前提下,启动执行一次性提交夜维(简称“夜维1”)成功复现问题:

1010-1

1010-2

与故障当晚现象基本一致,INDEX UNQIUE SCAN 单块读一行 居然需要22万左右逻辑读,成功复现了异常现象。

(2)阶段二:设置10019 event,随后应用切换至备集群重新连接生产数据库,使得重新初始化PGA,执行夜维程序与正常updaet应用叠加:

1010-3

1010-4

 

逻辑读有显著的降低,但是因为第一次测试与第二次测试执行的夜维程序所删除的数据不同,会有这么一种情况存在,执行过delete后,extent中存在大量的null block,所以涉及第二次update时,首先要重用之前的空间并非申请新空间,是否经过space serach cache不好说,但是个人理解,只要申请块存放空间,都需要经过space serach cache的,无论初始化新块还是重用原来的空块。

(3)阶段三:将应用切回主集群,再次执行夜维程序与update进行叠加,因为主应用集群未重启,PGA未重新初始化,10019应该只对后续连接生效,对未清空PGA的不生效,但是也存在对新连接update生效的可能性。

1st:第二次测试,清空PGA后

2nd:第三次测试,重新连接主集群,未重启过应用,PGA未初始化。

1010-5

1010-6

undo一致读,逻辑读均有所提升,但是提升的非常有限。

结论:经过本次测试,认为event 10019还是有效果的,但是不排除三次删除的夜维数据特征不一样的客观影响,所以目前已将10019在数据库中持久化生效,并且应用将夜维程序更改为分批提交,再进行后续观察。