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

数据和云

发布于 2020-06-04 11:25:30

6250

发布于 2020-06-04 11:25:30

每月关注：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的任务重叠，导致了最终问题。