13518219792
这篇文章主要讲解了“数据库中分区维护DDL导致DML异常中断举例分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“数据库中分区维护DDL导致DML异常中断举例分析”吧！
杜尔伯特ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！
今天有同事反馈一个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 CT's case doesn't 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异常中断举例分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
