oracle系統緊急故障處理方法

oracle
Oracle物理結構故障的處理方法：
Oracle物理結構故障是指構成資料庫的各個物理檔案損壞而導致的各種資料庫故障。這些故障可能是由於硬體故障造成的，也可能是人為誤操作而引起。所以我們首先要判斷問題的起因，如果是硬體故障則首先要解決硬體問題。在無硬體問題的前提下我們才能按照下面的處理方發來進一步處理。

控制檔案損壞：
控制檔案記錄了關於oracle的重要配置資訊，如資料庫名、字元集名字、各個資料檔案、記錄檔的位置等等資訊。控制檔案的損壞，會導致資料庫異常關閉。一旦缺少控制檔案，資料庫也無法啟動，這是一種比較嚴重的錯誤。
可以通過查詢資料庫的記錄檔來定位損壞了的控制檔案。記錄檔位於$ORACLE_BASE/admin/bdump/alert_ORCL.ora.

損壞單個控制檔案：
1. 確保資料庫已經關閉，如果沒有用下面的命令來關閉資料庫：
svrmgrl>shutdown immediate;
2. 查看初始設定檔案$ORACLE_BASE/admin/pfile/initORCL.ora,確定所有控制檔案的路徑。
3. 用作業系統命令將其它正確的控制檔案覆蓋錯誤的控制檔案。
4. 用下面的命令重新啟動資料庫
svrmgrl>startup;
5. 用適當的方法進行資料庫全備份。

損壞所有的控制檔案：
1. 確保資料庫已經關閉，如果沒有用下面的命令來關閉資料庫：
svrmgrl>shutdown immediate;
2. 從相應的備份結果集中恢複最近的控制檔案。對於沒有採用帶庫備份的點可以直接從磁帶上將最近的控制檔案備份恢複到相應目錄；對於採用帶庫備份的點用相應的rman指令碼來恢複最近的控制檔案。
3. 用下面的命令來建立產生資料庫控制檔案的指令碼：
svrmgrl>startup mount;
svrmgrl>alter database backup controlfile to trace noresetlogs;
4. 修改第三步產生的trace檔案，將其中關於建立控制檔案的一部分語句拷貝出來並做些修改，使得它能夠體現最新的資料庫結構。假設產生的sql檔案名稱字為createcontrol.sql.
注意：
Trace檔案的具體路徑可以在執行完第3）步操作後查看$ORACLE_BASE/admin/bdump/alert_ORCL.ora檔案來確定。
5. 用下面命令重新建立控制檔案：
svrmgrl>shutdown abort;
svrmgrl>startup nomount;
svrmgrl>@createcontrol.sql;
6. 用適當的方法進行資料庫全備份。

重做記錄檔損壞：
資料庫的所有增、刪、改都會記錄入重做日誌。如果當前啟用的重做記錄檔損壞，會導致資料庫異常關閉。非啟用的重做日誌最終也會因為日誌切換變為啟用的重做日誌，所以損壞的非啟用的重做日誌最終也會導致資料庫的異常終止。在ipas/mSwitch中每組重做日誌只有一個成員，所以在下面的分析中只考慮重做日誌組損壞的情況，而不考慮單個重做日誌成員損壞的情況。

確定損壞的重做日誌的位置及其狀態：
1. 如果資料庫處於可用狀態：
select * from v$logfile;
svrmgrl>select * from v$log;
2. 如果資料庫處於已經異常終止：
svrmlgr>startup mount;
svrmgrl>select * from v$logfile;
svrmgrl>select * from v$log;
其中，logfile的狀態為INVALID表示這組記錄檔出現已經損壞；log狀態為Inactive：表示重做記錄檔處於非啟用狀態；Active： 表示重做記錄檔處於啟用狀態；Current：表示是重做日誌為當前正在使用的記錄檔。

損壞的記錄檔處於非啟用狀態：
1. 刪除相應的日誌組：
svrmgrl>alter database drop logfile group group_number;
2. 重新建立相應的日誌組：
svrmgrl>alter database add log file group group_number （’log_file_descritpion’，…） size log_file_size;

損壞的記錄檔處於啟用狀態且為非當前日誌：
1. 清除相應的日誌組：
svrmgrl>alter database clear unarchived logfile group group_number;

損壞的記錄檔為當前活動紀錄檔案：
用命令清除相應的日誌組：
svrmgrl>alter database clear unarchived logfile group group_number;
如果清除失敗，則只能做基於時間點的不完全恢複。
開啟資料庫並且用適當的方法進行資料庫全備份：
svrmgrl>alter database open;

部分資料檔案損壞：
若損壞的資料檔案屬於非system資料表空間，則資料庫仍然可以處於開啟狀態可以進行操作，只是損壞的資料檔案不能訪問。這時在資料庫開啟狀態下可以單獨對損壞的資料檔案進行恢複。若是system資料表空間的資料檔案損壞則資料庫系統會異常終止。這時資料庫只能以Mount方式開啟，然後再對資料檔案進行恢複。可以通過查看資料庫記錄檔來判斷當前損壞的資料檔案到底是否屬於system資料表空間。

非system資料表空間的資料檔案損壞
1. 確定損壞的檔案名稱字：
svrmgrl>select name from v$datafile where status=’INVALID’;
2. 將損壞的資料檔案處於offline狀態：
svrmgrl>alter database datafile ‘datafile_name’ offline;

3. 從相應的備份結果集中恢複關於這個資料檔案的最近的備份。對於沒有採用帶庫備份的點可以直接從磁帶上恢複；對於用帶庫備份的點用相應的rman指令碼來恢複。
4. 恢複資料檔案：
svrmgrl>alter database recover datafile ‘file_name’;
5. 使資料庫檔案online：
svrmgrl>alter database datafile ‘datafile_name’ online;
6. 用適當的方法進行資料庫全備份。

system資料表空間的資料檔案損壞：
1. 以mount方式啟動資料庫
svrmgrl>startup mount;
2. 從相應的備份結果集中恢複關於這個資料檔案的最近的備份。對於沒有採用帶庫備份的點可以直接從磁帶上恢複；對於用帶庫備份的點用相應的rman指令碼來恢複。
3. 恢複system資料表空間：
svrmgrl>alter database recover datafile ‘datafile_name’;
4. 開啟資料庫：
svrmgrl>alter database open;
5. 用適當的方法進行資料庫全備份。

資料表空間損壞：
若非system資料表空間已經損壞，則資料庫仍然可以處於開啟狀態可以進行操作，只是損壞的資料表空間不能訪問。這樣在資料庫開啟狀態下可以單獨對損壞的資料表空間進行恢複。若是system資料表空間損壞則資料庫系統會異常終止。這時資料庫只能以Mount方式開啟，然後再對錶空間進行恢複。可以通過查看資料庫記錄檔來判斷當前損壞的資料表空間是否是system資料表空間.

非system資料表空間損壞：
1. 將損壞的資料表空間處於offline狀態：
svrmgrl>alter tablespace ‘tablespace_name’ offline;
2. 從相應的備份結果集中恢複關於這個資料表空間最近的備份。對於沒有採用帶庫備份的點可以直接從磁帶上恢複；對於用帶庫備份的點用相應的rman指令碼來恢複。
3. 恢複資料表空間：
svrmgrl>alter database recover tablespace ‘tablespace_name’;
4. 使資料表空間online：
svrmgrl>alter tablespace ‘tablespace_name’ online;
5. 用適當的方法進行資料庫全備份.

system資料表空間損壞：
1. 以mount方式啟動資料庫
svrmgrl>startup mount;
2. 從相應的備份結果集中恢複system資料表空間最近的備份。對於沒有採用帶庫備份的點可以直接從磁帶上恢複；對於用帶庫備份的點用相應的rman指令碼來恢複。
3. 恢複system資料表空間：
svrmgrl>alter database recover tablespace system;
4. 開啟資料庫：
svrmgrl>alter database open;
5. 用適當的方法進行資料庫全備份。

整個資料庫的所有檔案損壞：
整個資料庫所有檔案的損壞一般是在共用磁碟陣列發生無法恢複的災難時才發生，這種情況下只能對資料庫進行恢複。若資料庫的歸檔目錄也已經丟失，則資料庫不可能做完全恢複，會有使用者資料的丟失。

沒採用帶庫備份的現場：
1. 將最近的備份從磁帶上把各個檔案解包到相應的目錄下。
2. 以mount方式開啟資料庫：
svrmgrl>startup mount;
3. 恢複資料庫：
svrmgrl>recover database until cancel;
4. 開啟資料庫：
svrmgrl>alter database open resetlogs;
5. 用適當的方法進行資料庫全備份。

採用帶庫備份的現場：
1. 以nomount方式開啟資料庫：
svrmgrl>startup nomount;
2. 通過相應的rman指令碼進行資料庫軟恢複。
$rman cmdfile=hot_database_restore.rcv
3. 開啟資料庫：
svrmgrl>alter database open resetlogs;
4. 用適當的方法進行資料庫全備份。

存在最近的資料庫完整冷備份前提下的一些經典緊急情況的處理：
資料檔案，歸檔重作日誌和控制檔案同時丟失或損壞：
無新增archives 時的狀況：
條件和假設：自上次鏡像備份以來尚未產生新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像（冷）拷貝
恢複步驟：
1. 將鏡像拷貝的datafile(s) 和control file(s) 抄送回原始地點:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 選項啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以舊的control file 來恢複資料庫：
svrmgrl> recover database using backup controlfile until cancel;
*** 介質恢複完成
（必須馬上cancel ）
4. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
5. 關閉資料庫並做一次全庫冷備份。

新增archives 時的狀況：
條件和假設：自上次鏡像備份以來已經產生新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像（冷）拷貝；archive log(s) 可用。
恢複步驟：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份檔案抄送回原始地點：
所有Database Files
所有Control Files（沒有archive(s) 或redo(s) 的情況下，control files 的更新無任何意義）
所有On-Line Redo Logs (Not archives)
init.ora file（選項）
3. 啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup

資料檔案, 重作日誌和控制檔案同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的所有所失檔案的鏡像（冷）拷貝；archive log(s) 可用
恢複步驟（必須採用不完全恢複的手法）：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份檔案抄送回原始地點：
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
init.ora file（選項）
3. 啟動資料庫然而並不開啟：
svrmgrl>startup mount
4. 做不完全資料庫恢複，應用所有從上次鏡像（冷）備份始積累起來的archives：
svrmgrl> recover database until cancel using backup controlfile;
......
......
cancel
5. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
6. 關閉資料庫並做一次全庫冷備份。

資料檔案和控制檔案同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝；archive log(s) 可用
恢複步驟：
1. 將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 選項啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以舊的control file 來恢複資料庫：
svrmgrl> recover database until cancel using backup controlfile;
*** 介質恢複完成
（須在應用完最後一個archive log 後cancel ）
4. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;

重作日誌和控制檔案同時丟失或損壞時：
條件和假設：Control Files 全部丟失或損壞；Archivelog Mode; 有Control Files 的鏡像（冷）拷貝
恢複步驟：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
svrmgrl>exit
2. 以Control File 的鏡像（冷）拷貝覆蓋損壞了的Control File:
$ cp /backup/control1.ctl /disk1/control1.ctl
3. 啟動資料庫然而並不開啟：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
4. Drop 壞掉的redo log （排除硬體故障）：
svrmgrl> alter database drop logfile group 2;
5. 重新建立redo log:
svrmgrl> alter database add logfile group 2 '/orig_loc/log2.dbf' size 10M;
6. 以舊的control file 來恢複資料庫：
svrmgrl> recover database until cancel using backup controlfile;
（必須馬上cancel ）
7. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
8. 關閉資料庫並做一次全庫冷備份

只發生歸檔重作日誌丟失或損壞時：
根據不同環境和情況，選擇下述手段之一：
a. 馬上backup 全部datafiles （如果系統採用一般熱備份或RMAN 熱備份）
b. 馬上正常關閉資料庫並進行冷備份（如果系統採用冷備份）
c. 冒險前進！不做備份而讓資料庫接著跑，直等到下一個備份周期再做備份。這是在賭資料庫在下一個備份周期到來之前不會有需要恢複的錯誤發生。
注意:冒險前進的選擇：如果發生錯誤而需要資料庫恢複，則最多隻能恢複到出問題archive log 之前的操作現場。從另一個角度講，archive log(s) 出現問題時，資料庫若不需要恢複則其本身並沒有任何問題。

Oracle邏輯結構故障的處理方法：
邏輯結構的故障一般指由於人為的誤操作而導致重要資料丟失的情況。在這種情況下資料庫物理結構是完整的也是一致的。對於這種情況採取對原來資料庫的全恢複是不合適的，我們一般採用三種方法來恢複使用者資料。

採用exp/imp工具來恢複使用者資料：
如果丟失的資料存在一個以前用exp命令的備份，則可以才用這種方式。
1. 在資料庫內建立一個臨時使用者：
svrmgrl>create user test_user identified by test;
svrmgrl>grant connect，resource to test_user;
2. 從以前exp命令備份的檔案中把遺失資料的表按照使用者方式倒入測試使用者：
$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
3. 用相應的DML語句將丟失的資料從測試使用者恢複到原使用者。
4. 將測試使用者刪除：
svrmgrl>drop user test_user cascede;

採用logminer來恢複使用者資料：
Logminer是oracle提供的一個日誌分析工具。它可以根據資料字典對線上聯機日誌、歸檔日誌進行分析，從而可以獲得資料庫的各種DML操作的記錄以及各種DML操作的回退資訊。根據這些使用者就可以將由於誤操作而丟失的資料重新加入資料庫內。
1. 確認資料庫的utl_file_dir參數已經設定，如果沒有則需要把這個參數加入oracle的初始化參數檔案，然後重新啟動資料庫。下面例子中假設utl_file_dir=’/opt/oracle/db01’；
2. 建立logminer所需要的資料字典資訊，假設產生的資料字典文字檔為dict.ora：
svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora'， dictionary_location=>'/opt/oracle/db01’);
3. 確定所需要分析的日誌或者歸檔日誌的範圍。這可以根據使用者誤操作的時間來確定大概的日誌範圍。假設使用者誤操作時可能的記錄檔為/opt/oracle/db02/oradata/ORCL/redo3.log和歸檔日誌’/opt/oracle/arch/orcl/orclarc_1_113.ora’。
4. 建立要分析的記錄檔列表，按記錄檔的先後順序依次加入：
svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>’/opt/oracle/arch/orcl/orclarc_1_113.ora’，options=>dbms_logmnr.NEW);
svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>’ /opt/oracle/db02/oradata/ORCL/redo3.log’，options=>dbms_logmnr.ADDFILE);
5. 開始日誌分析，假設需要分析的時間在’2003-06-28 12:00:00’和’2003-06-28 13:00:00’之間：
svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>’ /opt/oracle/db01/dict.ora’，starttime=>to_date(’ 2003-06-28 12:00:00’，’YYYY-MM-DD HH:MI:SS’)，endtime=>to_date(to_date(‘2003-06-28 13:00:00’，’YYYY-MM-DD HH:MI:SS’));
6. 擷取分析結果：
svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;
7. 根據分析結果修複資料。
8.結束logmnr:
svrmgrl>dbms_logmnr.end_logmnr;
9. 用適當的方法對原資料庫進行資料庫全備份。

利用備份恢複使用者資料：
採用這種方法時並不是在原資料庫進行恢複，而是利用Database Backup在新的機器上重建立立一個新的資料庫。通過備份恢複在新機器上將資料庫恢複到使用者誤操作前，這樣就可以獲得丟失的資料將其恢複到原資料庫。
1. 在新的機器上安裝資料庫軟體。
2. 對於採用帶庫備份的現場，需要在新的資料庫伺服器上安裝調試相應的備份管軟體。
3. 根據使用者誤操作的時間點進行基於時間點的資料庫恢複操作。對於沒有採用帶庫備份的現場，可以選取使用者誤操作前最近的備份磁帶進行恢複；對於才用帶庫備份的點可以通過基於時間復原點恢複的rman指令碼來進行恢複。
4.重新開啟資料庫：
svrmgrl>alter database open resetlogs;
5. 從新的資料庫中擷取丟失的使用者資料，通過DML操作將其恢複到原資料庫中。
6. 用適當的方法對原資料庫進行資料庫全備份。