數據庫崩潰災難記實
2024-07-21 02:38:14
供稿：網友
環境: digital unix 4.0f, Oracle 7.3.4 , 雙機，陣列， raid5
備份方法是天天半夜12點自動eXP整個數據庫。
上午8:55，數據庫忽然掛起，alert文件的報錯信息如下：
Fri Dec 21 08:33:57 2001
Thread 1 advanced to log sequence 2076
Current log# 3 seq# 2076 mem# 0: /oradata/oracle7/oradata/ORA7/redoORA703.log
Fri Dec 21 08:54:33 2001
KCF: write/open error dba=0x8003dea block=0x3dea online=1
file=2 /oradata/oracle7/oradata/ORA7/rbs01.dbf
error=7376 txt: 'Digital Unix Error: 5: I/O error
Additional information: 15850'
馬上把此信息報告給unix系統治理A，A同事去機房處理....
此時，我還沒怎么著急，心想數據庫雖然很重要，但我有備份，大不了imp一遍。
我開始在網上查rbs損壞的處理方法，大約過了半個小時，A同事還沒消息，我想還是把exp出來的數據預備好吧，telnet上去一看
. . exporting table B_LIST
EXP-00014: error on row 10 of table B_LIST
EXP-00008: ORACLE error 1092 encountered
ORA-01092: ORACLE instance terminated. Disconnection forced
EXP-00222:
System error message 2
EXP-00008: ORACLE error 3114 encountered
ORA-03114: not connected to ORACLE
EXP-00222:
System error message 2
EXP-00000: Export terminated unsUCcessfully
EXP-00222:
System error message 2
差點暈倒，再往前看，好幾天的exp都不成功，頓時冷汗全出來了，有點虛脫，既而手腳冰涼。my god! 下屬40多個單位，60個帳套好幾年的財務數據全在上面，而且所有的EDI數據也全在上面...
。。。
大腦空白5分鐘
。。。
手有點抖，用最快的速度回想，發現最后一次全備份是12月11號，9天以前的，現在是年底，財務最忙的時候，要是讓他們補9天的數據還不把我給吃了.....A同事還是沒消息。。
開始深深自責，為什么昨天、前天、大前天、大大前天沒看一下備份成功沒有呢？！若看了不就能防患于未然，今天的事故不就不會發生了嗎？！為什么那么要懶那么一下呢？！......
兩分鐘后，開始打電話搬救兵，咨詢出一個認為是最好的恢復辦法，查資料，看這個方法的可行性，在紙上寫出具體步驟，在筆記本上重寫一遍，推敲步驟是否正確。
A同事那邊還是沒消息。。。
等待。。。
祈禱他那邊一切順利，數據文件完好無損，我祈禱。。。
時間過得好慢呀！
n年過去了，電話還沒響。。。
等。。。
電話終于響了，A同事說文件已經恢復了，讓我試一下。
當時很激動，深呼吸兩口，好象稍微平靜了點。 telnet上去
svrmgrl>connect internal
svrmgrl>startup
眼睛盯著屏幕，instance start, database mount..............database open, 長噓一口氣，心放了下來，又有點虛脫...
看看表，11:00，整整兩個小時，大悲大喜，深刻領悟了什么是DBA。
A同事回來了，說是磁盤有點故障，幸虧用的是RAID5，壞一塊盤沒問題。
開始做EXP，我都是在A服務器上備份B服務器上的數據，B服務器備份A服務器上的數據，這次發現速度奇慢無比，以為是數據庫問題，登錄查詢了幾個大表，速度跟以前比沒變化，在本機做EXP，一切OK。
回過頭來，再看看昨天、前天EXP的LOG文件，原來EXP太慢了，exp是數據庫崩潰的時候才斷的，所以有1092錯誤。my god！
一個很希奇的問題出現了，A機 EXP B機的數據沒問題，但是B機 EXP A機的數據就速度奇慢，出現3113錯誤，問題到現在還不知原因。
5：00下班。這就是一個DBA的一天。
