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. 關閉數據庫并做一次全庫冷備份。