轉自:http://www.cnblogs.com/liubiqu/archive/2006/09/11/501339.html
如何把數據文件從C盤移動到D盤呢？
很簡單，三個步驟就行了
第一步：把表空間Offline，把表空間的數據文件移動到D盤指定的目錄。
第二步：修改表空間文件路徑alter database rename file '舊文件路徑' to '新文件路徑';
第三步：把表空間Online，這樣就可以了。
以下是一些其它方面的參考：
數據文件重命名(filesystem and raw device)
filesystem
database must be open:
1.alter tablespace tbs read only;
2.alter tablespace tbs offline;
3.在offline時拷貝一份原文件，並命名爲新文件名
4.alter tablespace tbs rename datafile 'tbs_file_old.dbf' to 'tbs_file_new.dbf';
5.alter tablespace tbs online;
6.alter tablespace tbs read write;
7.alter database recover datafile 'tbs_file_new.dbf';
raw device
database must be mounted but not open:
1.爲新的數據文件創建裸設備鏈接文件
2.starup mount;
3.alter database rename file 'tbs_file_old' to 'tbs_file_new';
4.alter database recover datafile 'tbs_file_new';
5.alter database open;
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. 用適當的方法對原數據庫進行數據庫全備份。
利用備份恢復用戶數據：
採用這種方法時並不是在原數據庫進行恢復，而是利用數據庫備份在新的機器上重新建立一個新的數據庫。通過備份恢復在新機器上將數據庫恢復到用戶誤操作前，這樣就可以獲得丟失的數據將其恢復到原數據庫。
1. 在新的機器上安裝數據庫軟件。
2. 對於採用帶庫備份的現場，需要在新的數據庫服務器上安裝調試相應的備份管軟件。
3. 根據用戶誤操作的時間點進行基於時間點的數據庫恢復操作。對於沒有采用帶庫備份的現場，可以選取用戶誤操作前最近的備份磁帶進行恢復；對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復。
4.重新打開數據庫：
svrmgrl>alter database open resetlogs;
5. 從新的數據庫中獲取丟失的用戶數據，通過DML操作將其恢復到原數據庫中。
6. 用適當的方法對原數據庫進行數據庫全備份。
方法1：
1。安裝ORACLE軟件
2。運行DBCA，創建數據庫，位置什麼的隨便，只要SID，DBNAME，CHARACTERSET相同就得，到最後一步選保存爲腳本，不運行建庫，保存退出。
3。打開建庫腳本（。BAT），手工運行語句（例子）：
mkdir E:/oracle/admin/everac/bdump
mkdir E:/oracle/admin/everac/cdump
mkdir E:/oracle/admin/everac/create
mkdir E:/oracle/admin/everac/pfile
mkdir E:/oracle/admin/everac/udump
mkdir v:/database
mkdir v:/oradata/everac
set ORACLE_SID=everac1
E:/oracle/ora92/bin/oradim.exe -new -sid EVERAC1 -startmode m
E:/oracle/ora92/bin/oradim.exe -edit -sid EVERAC1 -startmode a
E:/oracle/ora92/bin/orapwd.exe file=E:/oracle/ora92/database/PWDeverac1.ora password=change_on_install
4。可以聯庫，打開數據庫。-----OVER
方法2
1.安裝ORACLE以後創建數據庫，所用的SID名稱、系統默認表空間數據文件的路徑都與原來的一樣，不需要建任何的其他用戶和表空間等等。
2。停調ORACLE服務，將原來數據庫admin、oradata文件夾覆蓋新安裝的文件夾。
3。更重要的是，要將initSID.ora文件，PWDSID.ora文件（密碼文件）替換新安裝後的文件，我的這兩個文件是在$ORACLE_HOME/database下。
4。另外，我還將$ORACLE_HOME/sysman/ifiles下的def_SID.ora文件替換了新安裝的文件（是否需要這一步我不敢確定，因爲我原來的系統配置了OEM，索性一起覆蓋得了）
5。重啓ORACLE成功，與原來的一樣。