共计 2273 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章主要讲解了“数据库中分区维护 DDL 导致 DML 异常中断举例分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“数据库中分区维护 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 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 异常中断举例分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
