五月数据库技术通讯丨Oracle 12c因新特性引发异常Library Cache Lock等待

每月关注：35页数据库技术干货，汇总一个月数据库行业热点事件、新的产品特性，包括重要数据库产品发布、警报、更新、新版本、补丁等。

亲爱的读者朋友：

为了及时共享行业案例，通知共性问题，达成共享和提前预防，以及共同学习国产数据库内容，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等，以及对国产数据库的一些突出能力的总结。

此文档原本是我们为重要客户整理的经典案例，现限时开放下载，希望可以帮助到读者朋友们。

目录

• 新闻：2020年5月数据库流行度排行
  

• 聚焦：MySQL DBA必备：MySQL 5.7升级8.0过程

• 警示：Oracle 12.2因未修复Bug导致LCK进程hang数据库异常

• 经验：超融合硬件损坏导致 Oracle RAC 异常恢复实录
  

• 经验：Oracle 12c 因新特性引发异常library cache lock等待

• 频发：故障排除之又见ORA-600

• 问题：dual引发的SQL性能故障诊断

• 公告：祝贺！墨天轮首批MVP名单出炉！
  
  

本文出自《云和恩墨技术通讯-2020.05》，下载原文地址：https://www.modb.pro/doc/4100（复制到浏览器中打开或者点击左下角“阅读原文”）

另：在“数据和云"公众号后台回复“云和恩墨技术通讯”即可查看并下载往期技术通讯集锦。

以下摘录于技术通讯其中一篇，希望对大家有帮助。

警示：Oracle 12c 因新特性引发异常library cache lock等待——李晴晴

---

library cache lock等待事件是Oracle数据库较为常见的等待事件之一，在之前的几次月刊中，我们也提到过产生library cache lock等待出现的原因有很多，如登录密码错误尝试过多、热表收集统计信息和SQL解析失败等。在Oracle 12c版本中，引入了一个新特性：分区表全局索引异步维护，这个新特性是指：当分区表有分区新增、删除、合并或truncate分区操作时，为了保证全局索引的有效性，通过调度JOB ( SYS.PMO_DEFERRED_GIDX_MAINT_JOB ) 默认在凌晨两点对全局索引进行维护。但是在特殊情况下会出现由于大量并发业务，造成异常library cache lock等待事件，造成数据库突发性能问题。在此，我们分享一次数据库性能故障的案例，供各位参考。

· 问题描述

某生产库收到异常告警信息，提示数据库出现大量等待告警。


当即登陆数据库，发现数据库出现大量library cache lock和library cache: mutex X等待。

· 问题分析

查看和异常等待事件相关的SQL，发现：


查看该SQL文本为：


insert into xxx.xx_LOG_INFO(xxx_ID,·······) values(:1 , :2 , :3 , :4 , :5  , :6 ) ;

而该SQL的执行计划并没有什么异常：

进一步分析ash，查看和异常等待事件相关的对象，发现：两个等待事件指向的object_id是相同的。

通过 object_id 查看对应的具体对象后，发现所有对象均和表 xxx. xx_LOG 相关。

此时，查看系统发现有一个进程正在进行 alter index 操作。

经查看：被操作的索引 PK_xx_LOG 为表 xxx.xx_LOG 的主键索引。

而这个进程发现是系统的一个job，在当天的凌晨2点触发执行：

这个job 是Oracle 12C 的新特性----分区表全局索引异步维护：

当分区表有分区新增、删除、合并或truncate分区操作时，为了保证全局索引的有效性，通过调度JOB ( SYS.PMO_DEFERRED_GIDX_MAINT_JOB ) 默认在凌晨两点对全局索引进行维护。当dba_indexes表中的ORPHANED_ENTRIES字段为YES时表示这个全局索引需要被维护。通过查看，表 xxx.xx_LOG 的主键索引PK_xxx_LOG 确实需要被维护。

查看表 xxx.xxLOG 的DDL语句证实该表为 每天自动增加一个分区 的分区表。一般情况下，如果增加的新分区内不包含表内现有数据，是不会导致全局分区索引失效，但在当天凌晨1点，系统自动增加一个分区(split)，新分区已经包括旧分区的部分数据，导致全局分区索引失效，从而触发了系统对全局索引的自动维护。而且该表比较大，维护分区索引的时间较长，从2点开始，到7点尚未结束，最终和大量insert的任务重叠，导致了最终问题。

通过向业务人员了解：表xxx.xx_LOG和xxx.xx_LOG_INFO是同时进行写入的。此时，故障原因变得十分清晰：

由于系统对表xxx.xx_LOG 上的主键索引进行维护，导致该表上的dml操作堵塞。而这两张表是同时进行写入，故通过查询SQL时出现的是另一张表，通过object_id查询时才发现问题所在。

· 问题解决

临时处理：经业务核实后将insert会话kill后，故障解决。

后续措施：

1. 将insert业务错峰运行，避免再次出现类似情况。
2. 批量增加分区表的分区，避免触发系统维护索引job运行。
3. 可能的话，避免使用全局分区索引

推荐阅读：144页！分享珍藏已久的数据库技术年刊

数据和云

ID：OraNews

如有收获，请划至底部，点击“在看”，谢谢！

点击下图查看更多 ↓

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂

  点个“在看”

你的喜欢会被看到❤