oracle bug号,《一次Oracle bug的故障排查过程思考》的问题重现解决

在《一次Oracle bug的故障排查过程思考》这个问题排查过程当中，当时和同事们一块儿猜想、实验、论证，昨天有幸，通过了精心设计，在生产环境中，进行了问题重现，以及解决的部分验证。sql

为了统计数据，在每次测试先后，各打印次AWR Snapshot。

shell

第一次测试

数据库

1. 应用：bash

使用旧的夜维(无批量提交，虽然delete操做一次删除10000条，可是会在删除全部数据(20万)完成的时候，才会作commit，约须要2分钟，即须要让相应数据和回滚表空间的数据块处于事务进行中状态约2分钟)。微信

2. 数据库：

网络

未设置10019，存在Bug 13641076的bugfix，未修复Bug 19791273。session

3. 执行过程：

app

当夜维执行到第10次左右的10000条delete操做，应用的响应时间开始变长，数据库CPU idle最低降到了60%左右了，正常时间段，CPU idle通常为80%-90%左右的。学习

4. 数据：测试

此次夜维执行，22:10-22:12，总计2分钟左右，检索对应业务的update语句逻辑读，从下图能够看出，相比其余小时段，增加了将近1000倍，

从SQL AWR看，这条update语句的逻辑读，大约是224986.5021057557，

一条使用惟一索引的update语句执行计划，已是很高效了，22万的逻辑读，就很不正常了，和Bug 19791273的现象Poor UPDATE SQL performance due to space search cache for updates on ASSM segment，非常相像的，

虽然没出现故障当天CPU idle为0的现象，可是有所降低，并且业务update语句的逻辑读，如此之高，应该算是复现了这个问题。

第二次测试

1. 应用：

使用旧的夜维，同时，业务切换至备份集群，重启备集群的链接池和应用，以让Bug 13641076描述的将space search cache从cursor存储改至session，须要重置链接，保证10019事件生效。

2. 数据库：

设置10019事件。

3. 执行过程：

夜维执行过程当中，业务的响应时间，基本保持不变，数据库CPU idle一直在80%-90%左右的，能够说如今夜维的执行对正常业务基本无影响。

4. 数据：

此次夜维执行，仍是2分钟左右，对应SQL AWR，显示update语句逻辑读，此次变成了44.78268251273345，

从现象上看，夜维执行中，业务update的逻辑读如今正常了，看来10019事件起到了做用。

第三次测试

1. 应用：

使用旧夜维，为了验证重启链接池的影响，将业务切换至主集群，可是不重启链接池和应用，按照假设和推理，当前数据库的10019在这套集群中，应该是未生效。

2. 数据库：

未作改动。

3. 执行过程：

夜维执行过程当中，应用的响应时间，略显提高，可是很是有限，数据库CPU idle最低降到75%，介于首次和第二次测试中间，能够说基本不存在影响。

4. 数据：

从SQL AWR看，update语句的逻辑读，大约是60.03633060853769，

虽然逻辑读和第二次相比，略有提高，但和首次的数据比较，天壤之别。一种可能，就是像《一次Oracle bug的故障排查过程思考》中猜想的，首次delete和update交叉执行，update已经找到了新的块空间，再次作相同数据的测试，虽然从数据层面来看，是从0变成了大值(CLOB)，可是从块空间看，是能够重用的，无需申请新的块空间，因此未出现逻辑读高的现象。

若是第一次测试，不作commit，而是在执行过程当中截断程序，此次测试接着用首次的数据，可能现象上就会更具说服力。

第四次测试

使用新夜维，即带批量提交的删除逻辑，从应用和数据库角度看，时间和CPU idle都和第二次测试相近，基本不存在delete对update的影响，此处不贴数据了。(假设：数据库未设置10019，使用新夜维，从理论上说，影响应该比第一次测试要小)。

从第一、二、3次测试的AWR Compare Report看，和bug中提到的space search cache做用可能相关联的指标，例如data blocks consistent reads - undo records applied，总量分别为479,50四、8,70五、25,186，从数据上，进一步支撑这个问题的猜想。

这个问题的复现和基本解决，在过程当中，确实学到了很多，如《应用执行慢的问题排查路径》所说的，对这种问题排查，除了须要数据库的知识，应用、网络、操做系统等方面的知识，均可能会用到，这就对人员的知识体系，提出了更高要求，正所谓“一专多能”，才是王道，从中看到了不足，仍是要向各位老师和同事，学习、请教。

P.S. AWR相关脚本和指令，

建立AWR Snapshot，

SQL>exec dbms_workload_repository.create_snapshot;

建立AWR，

SQL>@?/rdbms/admin/awrrpt

建立SQL AWR，

SQL>@?/rdbms/admin/awrsqrpt

建立AWR Compare，

SQL>@?/rdbms/admin/awrddrpt.sql