数据库中分区维护DDL导致DML异常中断举例分析

这篇文章主要讲解了“数据库中分区维护DDL导致DML异常中断举例分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“数据库中分区维护DDL导致DML异常中断举例分析”吧！

今天有同事反馈一个insert语句执行时异常中断，报错信息是:ERROR at line 1:

ORA-12805: parallel query server died unexpectedly

这个报错可能的原因很多，没太多价值，检查对应时间点的后台alert和trace文件，发现有7445报错

ORA-07445: exception encountered: core dump [kdzt_acmp_project()+124] [SIGSEGV] [ADDR:0x0] [PC:0x308DF84] [SI_KERNEL(general_protection)] []

第一反应是遇到BUG了，上MOS查了下，发现Bug 24301654的报错信息和我这个有点像，贴一部分出来,除了内存地址不同别的基本相同

Problem Key: ORA-7445 [kdzt_acmp_project()+124]

Error: ORA-7445 [kdzt_acmp_project()+124] [SIGSEGV] [ADDR:0x0] [PC:0x2DB1BB0]

[SI_KERNEL(general_protection)] [] [] [] [] [] [] []

但看了下SR的回复- Bug 21097914 is similar, but CTs case doesnt have ">= rowid" predicates.我这个语句也没用到rowid范围扫，又看了下trace文件，看到一些类似如下的内容

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

true                 _is_lock_table_for_ddl_wait_lock= 1

遂怀疑是当时该表或分区有DDL操作导致，INSERT的目标表是分区表，并且每个小时都会有分区维护操作，检查对应时间点前后的分区维护日志，看到时间确实有重合的地方，又看了一下当时的等待事件，

library cache lock                                                       65

library cache: mutex X                                               23

平时这个等待事件很低，这里确实比平时高了

于是做了一下测试:

1.新建一个测试分区表，并建立少量相同命名的分区

2.A窗口执行当时的insert语句

3.很快在另个窗口(B窗口)执行分区维护语句，包括1个add partition,1个truncate partition和1个drop partition操作

4.如预期一样，A窗口出现了

insert /*+APPEND */ into xxxxx PARTITION(xxxxxxx) NOLOGGING

*

ERROR at line 1:

ORA-12805: parallel query server died unexpectedly

然后在A窗口执行一段时间后再执行分区维护语句，发现A窗口是可以正常执行结束的，之后又试了将3个分区维护命令分开操作，对A窗口的语句也不会有影响，结合以上情况个人判断是:

当DML sql语句还处于解析阶段时(该语句很长，并包含大量的聚合函数):

如果发起耗时稍长的DDL语句，会导致解析失败并报错，

如果解析结束再执行DDL，就不会导致DML语句中断，

如果DDL时间很短，也可以完成解析并正常执行DML

本来还想做个trace，时间有限就不继续研究了，先提醒研发尽量先执行分区维护再执行DML(都放在同个存储过程里)，应该就可以避免这个问题了，之前还遇到很多ORA-07445都是BUG导致，难得遇到一个应该不是BUG的07445，感觉值得记录一下

180507update：

最后ORACLE原厂的结论是命中了BUG 21097914，打对应patch或升级到12.1.0.2.170418之后的版本均可修复

感谢各位的阅读，以上就是“数据库中分区维护DDL导致DML异常中断举例分析”的内容了，经过本文的学习后，相信大家对数据库中分区维护DDL导致DML异常中断举例分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！