建立物化檢視導致資料庫例項崩潰
這個BUG是在9204上碰到的最嚴重的一個bug,在建立物化檢視的時候,直接導致了例項的崩潰。
物化檢視的建立指令碼就不貼出來了,語句比較長,其中大部分表是透過資料庫鏈訪問,而且還包括了樹狀查詢,但是,物化檢視功能並不複雜,既不是REFRESH FAST也不是ON COMMIT,更不是基於查詢重寫的。
使用者程式包括如下的錯誤資訊:
ORA-07445: exception encountered: core dump [00000001009FC6B0] [SIGSEGV] [Address not mapped to object] [0x000000008] [] []
Current SQL statement for this session:
CREATE SUMMARY "MIS2"."MIS2_GPO_ORDER_ITEM" COMPILE
而從後臺PMON程式的日誌檔案可以看到下面的錯誤:
Oracle process number: 2
Unix process pid: 7920, image: oracle@newreport (PMON)
ORA-07445: exception encountered: core dump [0000000100AE6CF4] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
.
.
.
ORA-07445: exception encountered: core dump [0000000100AE6640] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [0000000100AE6CF4] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
.
.
.
ORA-07445: exception encountered: core dump [0000000100AE6640] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [0000000100AE6640] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [0000000100AE6CF4] [SIGSEGV] [Address not mapped to object] [0xFFFFFFFF7CCF32C8] [] []
使用者程式7445錯誤的第一個錯誤引數是qsmkzii_init_qsmksinline。而PMON程式後臺檔案的錯誤函式分別是kksheqd和kkshlcu。
根據這些資訊在METALINK上查詢發現,最接近的bug為:Bug 3004764。
Bug 3004764 PMON may crash the instance with ORA-7445[KKSHEQD] / ORA-7445[KKSHLCU]
This note gives a brief overview of bug 3004764.
Affects:
Product (Component) | (Rdbms) |
Range of versions believed to be affected | Versions >= 9.0.1.4 but < 10G |
Versions confirmed as being affected |
|
Platforms affected | Generic (all / most platforms affected) |
It is believed to be a regression in default behaviour thus:
· Regression introduced in 9.0.1.4
Regression introduced in 9.2.0.2
Fixed:
This issue is fixed in |
|
Symptoms:
- Dump in or under kkshlcu
Related To:
- (None Specified)
Description
PMON may crash the instance by dumping with ORA-7445[KKSHEQD] or ORA-7445[KKSHLCU] when cleaning up a dead process if the process being cleaned up died (or was killed) at a specific point in the code.
The problem only occurs for specific scenarios and is most likely to occur if the aborted session was running DDL at the time it died.
這還是第一次碰到可以導致例項崩潰的BUG,不過想要避免這個bug也不算太過於困難。實踐再一次證明,越複雜的功能越容易導致bug的產生。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4227/viewspace-69333/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫的物化檢視資料庫
- 儲存崩潰導致資料丟失如何處理
- iOS開發-stringByEvaluatingJavaScriptFromString導致崩潰iOSJavaScript
- 執行緒崩潰為什麼不會導致 JVM 崩潰執行緒JVM
- 伺服器磁碟離線導致RAIDZ崩潰資料恢復伺服器AI資料恢復
- oracle資料庫建立資料庫例項-九五小龐Oracle資料庫
- Oracle物化檢視的建立及使用(二)Oracle
- Oracle物化檢視的建立及使用(一)Oracle
- 物化檢視
- 多塊硬碟離線導致raid6崩潰的資料恢復案例硬碟AI資料恢復
- 物化檢視如何快速完成資料聚合操作?
- 模態對話方塊可能導致程式崩潰
- A站大流量導致服務崩潰異常分析
- 誤升級GLIBC導致系統崩潰之後
- 物化檢視(zt)
- 【伺服器資料恢復】磁碟物理故障導致RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 記一次ORA-01102導致資料庫例項無法啟動案例資料庫
- 【北亞企安資料恢復】RAIDZ多塊磁碟離線導致崩潰的資料恢復案例資料恢復AI
- 【北亞資料恢復案例】raid0硬碟故障導致伺服器崩潰的資料恢復資料恢復AI硬碟伺服器
- 【伺服器資料恢復】raid6崩潰導致分割槽丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】磁碟壞道故障導致RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】意外斷電導致linux伺服器崩潰的資料恢復案例伺服器資料恢復Linux
- 資料庫崩潰恢復表結構的方法資料庫
- win10查詢崩潰日誌方法 win10怎麼檢視崩潰日誌Win10
- 【伺服器資料恢復】raid5硬碟離線導致EVA儲存崩潰資料恢復案例伺服器資料恢復AI硬碟
- 【伺服器資料恢復】raid5故障導致上層應用崩潰的資料恢復案例伺服器資料恢復AI應用崩潰
- 【伺服器資料恢復】伺服器進水導致伺服器崩潰的資料恢復案例伺服器資料恢復
- 汽車之家基於 Apache Flink 的跨資料庫實時物化檢視探索Apache資料庫
- Kdump 檢查 Linux 核心崩潰!Linux
- 記錄一個LifeCycle 多執行緒使用導致的崩潰執行緒
- 伺服器資料恢復—VMware下誤重灌系統導致伺服器崩潰的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】RAID5崩潰導致上層OA不可用的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】離線硬碟強制上線導致RAID5崩潰的資料恢復伺服器資料恢復硬碟AI
- 【伺服器資料恢復】RAID5崩潰後強制上線導致故障的資料恢復案例伺服器資料恢復AI
- 資料泵匯出匯入物化檢視(ORA-39083)
- 達夢資料庫建立檢視&MyBatis表能不能關聯檢視資料庫MyBatis
- 資料庫檢視資料庫
- 資料庫-檢視資料庫
- 手把手教你檢視和分析iOS的crash崩潰iOS