項(xiàng)目背景:oracle11G,一個(gè)禮拜前做了數(shù)據(jù)庫(kù)遷移
5月27號(hào)把虛擬機(jī)的oracle數(shù)據(jù)庫(kù)rac，遷移到現(xiàn)有的物理機(jī)上面，運(yùn)行了1個(gè)多禮拜沒有問題；

客戶讓執(zhí)行一個(gè)存儲(chǔ)過程，我尼瑪剛執(zhí)行就報(bào)錯(cuò)了GG

ORA-01578: ORACLE 數(shù)據(jù)塊損壞 (文件號(hào) 87, 塊號(hào) 4189572)
ORA-01110: 數(shù)據(jù)文件 87: '+DATA/XXglrac/datafile/XX_data.319.1136376323'
ORA-26040: 數(shù)據(jù)塊是使用 NOLOGGING 選項(xiàng)加載的
ORA-06512: 在 "XX.TEST1", line 46
ORA-06512: 在 "XX.TEST2", line 5
ORA-06512: 在 line 2

趕緊找DBA協(xié)助排除，我艸，DBA說 數(shù)據(jù)庫(kù)有壞塊，得用備份blockrecover了，關(guān)鍵是這個(gè)壞塊可能很早之前就存在了，現(xiàn)在得數(shù)據(jù)庫(kù)不一定能恢復(fù)處理;

只能從5月27號(hào)得老庫(kù)拿數(shù)據(jù)，完蛋了1個(gè)多禮拜的數(shù)據(jù)可能丟失，搞不好要打包跑路了

什么配置都沒有修改，重啟一下oracle實(shí)例，oracle打開就崩，雪上加爽，這尼瑪數(shù)據(jù)庫(kù)蹦了…（ORA-07445）
全庫(kù)還原3T，今天晚上怎么過？？？
oracle報(bào)錯(cuò)信息

Starting background process EMNC
EMNC started with pid=88, OS id=28326
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x28] [PC:0x7FC89503CAC8, java_util_HashMap__initHashSeedAsNeeded()+128] [flags: 0x0, count: 1]
Errors in file /u01/app/oracle/diag/rdbms/xxxrac/xxxrac1/trace/xxxrac1_ora_1103.trc  (incident=838370):
ORA-07445: exception encountered: core dump [java_util_HashMap__initHashSeedAsNeeded()+128] [SIGSEGV] [ADDR:0x28] [PC:0x7FC89503CAC8] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/xxxrac/xxxrac1/incident/incdir_838370/xxxrac1_ora_1103_i838370.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2023-06-06 21:20:45.687000 +08:00
Dumping diagnostic data in directory=[cdmp_20230606212045], requested by (instance=1, osid=1103), summary=[incident=838370].
PMON (ospid: 31124): terminating the instance due to error 397
System state dump requested by (instance=1, osid=31124 (PMON)), summary=[abnormal instance termination].

各種百度，總結(jié)后的數(shù)據(jù)庫(kù)操作流程,最終是:無(wú)法啟動(dòng)是oralce補(bǔ)丁導(dǎo)致的，回退了就可以了

1）全庫(kù)恢復(fù)到20230606 20:00，恢復(fù)完了還是無(wú)法開，打開就崩
2）嘗試startup upgrade，數(shù)據(jù)庫(kù)可以打開，結(jié)合告警推測(cè)可能是ojvm補(bǔ)丁的問題，回滾后重建java可以打開數(shù)據(jù)庫(kù)
3）有壞塊的表依然存在，truncate以后從舊庫(kù)dump導(dǎo)入，全表掃描后可以查詢所有數(shù)據(jù)
4）嘗試backup validate相關(guān)datafile，V$DATABASE_BLOCK_CORRUPTION里面的數(shù)據(jù)沒有刷新，依然顯示有壞塊，應(yīng)該是block數(shù)據(jù)沒有刷新的問題，我覺得可以忽略
5）在執(zhí)行升級(jí)程序，目前沒有報(bào)錯(cuò)

最后反饋給客戶評(píng)估

1.數(shù)據(jù)庫(kù)全庫(kù)恢復(fù)到2023年06月06日 20:00，恢復(fù)后仍然出現(xiàn)無(wú)法打開數(shù)據(jù)庫(kù);根據(jù)報(bào)錯(cuò)判斷是Oracle ovjm補(bǔ)丁bug導(dǎo)致，于是執(zhí)行了回滾ojvm操作，之后可以打開數(shù)據(jù)庫(kù)。
2.打開數(shù)據(jù)庫(kù)后仍然提示有數(shù)據(jù)壞塊，于是清空了壞塊相關(guān)的8張表，并從舊庫(kù)中導(dǎo)出了8張表的數(shù)據(jù)導(dǎo)入,之后數(shù)據(jù)庫(kù)狀態(tài)一切正常，
3.執(zhí)行了數(shù)據(jù)庫(kù)升級(jí)操作后，weblogic 啟動(dòng)正常，登入系統(tǒng)，訪問正常，業(yè)務(wù)查詢正常。
4.從舊系統(tǒng)導(dǎo)入的8張表
除了XXXX表，之外的7張表本來(lái)在此次數(shù)據(jù)庫(kù)發(fā)布操作中按腳本執(zhí)行也會(huì)清空操作，并重新生成。

XXXX表恢復(fù)使用的是5月27日的xxx數(shù)據(jù)庫(kù)中的數(shù)據(jù),恢復(fù)之后、操作完今天凌晨的數(shù)據(jù)庫(kù)發(fā)布操作后，
我們看到表中數(shù)據(jù)最新時(shí)間戳也是6月7日凌晨4點(diǎn)多的數(shù)據(jù)。


5.不確定表XXXX表是否存在數(shù)據(jù)丟失，請(qǐng)?jiān)u估。

百度和問CHATGPT給出的相關(guān)信息
https://blog.51cto.com/miracle/57178
我們執(zhí)行的存儲(chǔ)過程中有一個(gè)delete語(yǔ)句；

https://www.cnblogs.com/hmwh/p/12168390.html

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-474382.html

到了這里，關(guān)于數(shù)據(jù)庫(kù)宕機(jī)了-搞不好得打包滾蛋的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！