數(shù)據(jù)庫中分區(qū)維護DDL導致DML異常中斷舉例分析

這篇文章主要講解了“數(shù)據(jù)庫中分區(qū)維護DDL導致DML異常中斷舉例分析”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數(shù)據(jù)庫中分區(qū)維護DDL導致DML異常中斷舉例分析”吧！

今天有同事反饋一個insert語句執(zhí)行時異常中斷，報錯信息是:ERROR at line 1:
ORA-12805: parallel query server died unexpectedly

這個報錯可能的原因很多，沒太多價值，檢查對應時間點的后臺alert和trace文件，發(fā)現(xiàn)有7445報錯

ORA-07445: exception encountered: core dump [kdzt_acmp_project()+124] [SIGSEGV] [ADDR:0x0] [PC:0x308DF84] [SI_KERNEL(general_protection)] []
第一反應是遇到BUG了，上MOS查了下，發(fā)現(xiàn)Bug 24301654的報錯信息和我這個有點像，貼一部分出來,除了內(nèi)存地址不同別的基本相同
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文件，看到一些類似如下的內(nèi)容
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

遂懷疑是當時該表或分區(qū)有DDL操作導致，INSERT的目標表是分區(qū)表，并且每個小時都會有分區(qū)維護操作，檢查對應時間點前后的分區(qū)維護日志，看到時間確實有重合的地方，又看了一下當時的等待事件，
library cache lock                                                       65
library cache: mutex X                                               23
平時這個等待事件很低，這里確實比平時高了

于是做了一下測試:
1.新建一個測試分區(qū)表，并建立少量相同命名的分區(qū)
2.A窗口執(zhí)行當時的insert語句
3.很快在另個窗口(B窗口)執(zhí)行分區(qū)維護語句，包括1個add partition,1個truncate partition和1個drop partition操作
4.如預期一樣，A窗口出現(xiàn)了
insert /*+APPEND */ into xxxxx PARTITION(xxxxxxx) NOLOGGING
*
ERROR at line 1:
ORA-12805: parallel query server died unexpectedly

然后在A窗口執(zhí)行一段時間后再執(zhí)行分區(qū)維護語句，發(fā)現(xiàn)A窗口是可以正常執(zhí)行結(jié)束的，之后又試了將3個分區(qū)維護命令分開操作，對A窗口的語句也不會有影響，結(jié)合以上情況個人判斷是:
當DML sql語句還處于解析階段時(該語句很長，并包含大量的聚合函數(shù)):
如果發(fā)起耗時稍長的DDL語句，會導致解析失敗并報錯，
如果解析結(jié)束再執(zhí)行DDL，就不會導致DML語句中斷，
如果DDL時間很短，也可以完成解析并正常執(zhí)行DML
本來還想做個trace，時間有限就不繼續(xù)研究了，先提醒研發(fā)盡量先執(zhí)行分區(qū)維護再執(zhí)行DML(都放在同個存儲過程里)，應該就可以避免這個問題了，之前還遇到很多ORA-07445都是BUG導致，難得遇到一個應該不是BUG的07445，感覺值得記錄一下

180507update：
最后ORACLE原廠的結(jié)論是命中了BUG 21097914，打?qū)猵atch或升級到12.1.0.2.170418之后的版本均可修復

感謝各位的閱讀，以上就是“數(shù)據(jù)庫中分區(qū)維護DDL導致DML異常中斷舉例分析”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對數(shù)據(jù)庫中分區(qū)維護DDL導致DML異常中斷舉例分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！