ORA-01157錯誤解決
ORA-1157錯誤解決手冊
一．錯誤描述
ORA-1157, "cannot identify/lock data file %s - see DBWR trace file"
引起的原因：
因為資料檔案已經在被使用了從而導致資料庫的後臺程式不能找到相應的資料檔案或者不能鎖定相應的資料檔案，這樣資料庫將禁止訪問這些資料檔案而其他的資料檔案則沒有影響。伴隨這個錯誤作業系統將會提示是哪個資料檔案不能被識別。
ORA-01157錯誤一般和ORA-01110錯誤一起出現，往往還有作業系統級別上的錯誤，例如ORA-07360，同時一個DBWR的trace檔案會在background_dump_dest的目錄下生成。例如，在Solaris的平臺上，會有如下的錯誤資訊顯示：
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/export/home/Oracle/oradata/817/users01.dbf'
然後檢視DBWR的trace檔案內容，會有如下的內容：
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/export/home /Oracle/oradata/817/users01.dbf'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
下面就幾個容易產生ORA-1157錯誤的方面詳細談談：
二． 通常引起ORA-1157錯誤的原因和解決方法
如果你是使用Oracle9i，就用SQLPLUS代替SVRMGRL執行以下的命令。
1． 資料檔案存在，但是Oracle認不到它
這種情況可能是在作業系統級上資料檔案被重新命名了或者移動到了一個新的分割槽或者位置，這種情況比較簡單，只是需要將資料檔案恢復成原始的資料檔名字或者重新命名資料檔案到一個新的位置/目錄就可以解決問題了。
重新命名資料檔案到一個新的位置/目錄的方法：
A. 資料庫是開啟狀態的
1）檢視那個資料檔案所在的表空間還包含有哪些資料檔案，執行以下查詢：
SELECT FILE_NAME, STATUS FROM DBA_DATA_FILES
WHERE TABLESPACE_NAME = ''；
2）確定所有資料檔案的狀態都是可用的。
3）把表空間變成只讀表空間：
ALTER TABLESPACE READ ONLY；
4）確定在資料字典中表空間是顯示為只讀的：
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = ''；
TABLESPACE_NAME STATUS
------------------------------ ---------
READ ONLY
5）用作業系統命令複製資料檔案到一個新的位置，複製完成後把整個表空間
OFFLINE，這個時候使用者是不能訪問這個表空間的：
ALTER TABLESPACE OFFLINE；
6）重新命名這個資料檔案到一個新的位置了，這個操作會自動的更新控制檔案中的內容：
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；
7）ONLINE這個表空間：
ALTER TABLESPACE YOUR_TABLESPACE_NAME ONLINE；
8）把這個表空間置成可讀寫的狀態：
ALTER TABLESPACE YOUR_TABLESPACE_NAME READ WRITE；
9）在作業系統級上刪除原來舊的資料檔案。
B．資料庫是關閉狀態的
1） 先正常關閉資料庫。
2） 用作業系統命令複製資料檔案到一個新的位置。
3） MOUNT資料庫，這樣將讀取控制檔案，但是不會讀取資料檔案：
STARTUP MOUNT
4) 重新命名這個資料檔案到一個新的位置了，這個操作會自動的更新控制檔案中的內容：
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；
5） 開啟資料庫：
ALTER DATABASE OPEN；
2． 資料檔案不存在或者對於Oracle來說是不可用的
資料檔案被物理的移走了或者損壞導致Oracle不能再認到了，例如資料檔案被截斷或者覆蓋了，一般會出現ORA-27046、ORA-1157的錯誤提示：
ORA-27046: file size is not a multiple of logical block size
這種情況下可以有兩種選擇去解決問題：
A． 重建資料檔案所屬的那個表空間
這種方法比較適用於USERS、TEMP、INDEX表空間，如果資料庫是正常關閉的，也就是說回滾段中沒有啟用的表空間事務,也推薦使用這種方法。如果是SYSTEM表空間，則要重建資料庫了。
具體步驟如下：
1） MOUNT資料庫：
STARTUP MOUNT PFILE=''；
2） OFFLINE DROP資料檔案：
ALTER DATABASE DATAFILE '' OFFLINE DROP；
3） 開啟資料庫：
ALTER DATABASE OPEN；
4） 刪除表空間：
DROP TABLESPACE INCLUDING CONTENTS；
5） 重建表空間：
CREATE TABLESPACE DATAFILE
' SIZE ；
6） 重建表空間中所有以前存在的物件:可以使用以前建立物件的指令碼或者利用最近可用的EXPORT DUMP來重建以前存在的物件。
B．用正常的恢復過程去恢復資料檔案
這種方法比較適用於只讀表空間或者那種不能用重建表空間的方法的USERS和INDEX表空間。如果是回滾段表空間，那必須要求資料庫是正常關閉的才能使用這個方法。如果是SYSTEM表空間，並且備份和所有的歸檔日誌都全的情況下，強烈建議使用這種方法去恢復的，但是如果是非歸檔方式，則就只能利用當前所有的聯機日誌進行恢復了。
在很多的情況下，重建表空間是不可能的或者是非常費時費力的，因此，從備份和利用歸檔日誌恢復資料檔案是一種比較好的方法，尤其是對於只讀表空間來說，因為沒有資料的寫入和更改，因此直接用備份來恢復是最快最省事的。
具體步驟如下：
1） 從備份中恢復丟失或者損壞的資料檔案。
2） MOUNT資料庫：
STARTUP MOUNT PFILE=''；
3） 執行以下的查詢：
SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP#；
這個查詢將列出所有聯機重做日誌以及它們所代表的SEQUENCE和FIRST CHANGE NUMBER.
4） 如果資料庫是非歸檔狀態下的，執行以下的查詢：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE；
如果CHANGE#大於最小的聯機重做日誌檔案的FIRST_CHANGE#，那麼資料檔案可以被恢復，記住恢復資料檔案的時候要應用所有的聯機重做日誌檔案，然後到第5步。
如果CHANGE#小於最小的聯機重做日誌檔案的FIRST_CHANGE#，那麼這個資料檔案將不能被恢復了，那麼只能從最近的資料庫全備份恢復或者重建這個資料檔案所屬的表空間了。
5） 恢復資料檔案：
RECOVER DATAFILE ''；
6） 確認所有的歸檔日誌都被應用了直至出現"Media recovery complete"的提示資訊，如果Oracle提示有一個不存在的歸檔日誌檔案，那麼就可能要應用所有的聯機重做日誌檔案來恢復直至出現"Media recovery complete"的提示資訊。
7） 開啟資料庫：
ALTER DATABASE OPEN；
3． 資料庫臨時表空間的資料檔案的丟失
當資料庫的臨時表空間的資料檔案丟失也會引起ORA-01157的錯誤。因為資料庫對臨時表空間的資料檔案不會發生檢查點，所以這個時候資料庫照樣能夠開啟。這種情況下的解決方法是邏輯上刪除臨時表空間的資料檔案，並且重新增加一個新的臨時表空間的資料檔案。
例如：
SELECT * FROM DBA_OBJECTS ORDER BY OBJECT_NAME；
select * from dba_objects order by object_name；
* ERROR at line 1:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/Oracle/oradata/temp01.dbf'
ALTER DATABASE TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ DROP；
SELECT TABLESPACE_NAME,FILE_NAME FROM DBA_TEMP_FILES；
ALTER TABLESPACE TEMP ADD TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ SIZE 100M；
三．由於作業系統的問題或者第三方軟體的問題導致ORA-01157錯誤
1． 當使用vxfddstat去訪問快速I/O或者其它的應用，會獲得"Cannot open file"的錯誤，而Oracle會返回如下的錯誤：
ORA-01157: cannot identify data file 1 - file not found
ORA-01110: data file 1: ''
這個時候使用者應該去聯絡Veritas的技術支援，技術支援網站網址為。
2． 在HP-UNIX的機器上，如果系統核心引數nflock設定不是足夠大的時候，這樣可能會使Oracle不能鎖定所需要的資料檔案而導致錯誤：
ORA-27086: skgfglk: unable to lock file - already in use
或者錯誤：
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-0110: data file 4: '/Oracle/oradata/user01.dbf'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
或者錯誤：
ORA-07445: exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]
ORA-01110: data file %s: '%s'
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01115: IO error reading block from file %s (block # %s)
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 3
解決這個問題的方法是增大相關的核心引數：（建議以下的配置）
nproc 4096 Max Number of Processes
nfile 63488 Max Number of Open Files
nflocks 4096 Max Number of File Locks
3． 如果Oracle需要的資料檔案被其他程式鎖定的條件下也會導致這個錯誤。
例如：備份軟體將可能鎖定要備份的資料檔案
在WINDOWS上可能會有如下的錯誤：
ORA-01157: signalled during alter database open
ORA-01157: can not identify datafile
ORA-01110: datafile path and filename of datafile
ORA-27047: Unable to read header of file
OSD-04006: Read file failure
Error 33: process can not access file
作業系統錯誤33是一個error_lock_violation，表明一部分資料檔案被WINDOWS的其他程式鎖定了。
或者錯誤：
ORA-1157 - cannot identify datafile - file not found
ORA-1110 - datafile :
ORA-9202 - sfifi: error identifying file
OSD-4006(OS 203) - The System could not find the
environment option that was entered
在ALERT檔案中將會同時出現以下的錯誤：
ORA-1115 - IO error reading block from file %s (block # %s)
ORA-1110 - datafile :
ORA-9206 - sfrfb: error reading from file
OSD-4006(OS 203) - The System Could not find the environment
option that was entered
或者錯誤：
ORA-1242 - data file suffered media failure: database in NOARCHIVELOG mode
ORA-1114 - IO error writing block to file block #
ORA-9205 - sfqio: error reading or writing to disk
OSD-4016(OS 33) - The process cannot access the file because another
process has locked a portion of the file
另外還可能會出現以下錯誤：
KCF: write/open error dba=0x703473d block=0x3473d online=1
file=7 E:Oracledatagreccrecind2.dbf
error=9211 txt: 'OSD-4008 : WriteFile error (OS 203) - The System
Could not find the environment option that was entered
某些情況下ALERT檔案中會出現：
Instance terminating due to error 1110.
Instance terminated by PID=XXX
或者：
TERMINATING INSTANCE DUE TO ERROR 472
ORA 472 - PMON process terminated with error
在WINDOWS的事件檢視器中可以看到以下事件：
23 Error ReadFile() failure
25 Error WriteFile() failure
如果這是個冷備份，那就要等冷備份完成後啟動資料庫或者結束冷備份啟動資料庫。對於備份軟體，最好都配置成不要鎖定開啟的資料檔案的備份方式。
這種情況的解決方法是手工的清除在資料檔案上的鎖：
1） 執行ps -ef | grep ，查出在資料檔案上已經存在的程式。
2） 執行kill –9 程式ID
4． 使用WINDOWS的FILE MANAGER複製Oracle的資料檔案的時候也會引起ORA-01157的錯誤，例如檔名大於通常用的8.3格式，如果檔名大於8個字元或者你的副檔名大於3個字元就會引起這個錯誤。要避免這個錯誤，在WINDOWS下複製檔案不要用FILE MANAGER，最好使用瀏覽器去複製檔案，如果已經使用FILE MANAGER，那麼對於長檔名的檔案會自動加上一個～，這樣要重新命名複製的檔案為原來的檔名字。
5． 使用網路應用工具也可能會引起ORA-01157的錯誤。
在一些網路工具的使用操作中要求對資料檔案進行加鎖，如果由於例項錯誤或者主機的問題可能會導致這些鎖會一直的存在，這種情況下需要系統管理員手工的去釋放這些鎖。
6． 如果Oracle的資料檔案被一個其他的使用者恢復也可能引起ORA-01157的錯誤。
在Oracle的資料檔案被恢復之後，Oracle資料庫認不到恢復後的資料檔案，因此錯誤ORA-1157 (cannot identify datafile - file not found)就可能發生：
???? 資料檔案在作業系統上是否存在
???? SELECT * FROM V$DATAFILE檢視資料檔案的正確路徑
???? ALTER SYSTEM CHECK DATAFILE是否成功
???? 使用BACKUP CONTROLFILE TO TRACE檢視資料檔案的正確路徑
一般出現這種問題有可能是作業系統上的許可權問題，首先檢視資料檔案的許可權，當資料檔案被其他使用者恢復的時候可能許可權就變了，可能Oracle使用者就不能訪問了，這樣就要對恢復後的資料檔案修改許可權和屬主。
7． ULIMIT設定的值不夠大也可能會引起ORA-01157的錯誤。
在DBWR的跟蹤檔案中會有ORA-1157和ORA-27092的錯誤：
ORA-01157: cannot identify/lock data file N - see DBWR trace file
ORA-01110: data file 1: ''
ORA-27092: skgfofi: size of file exceeds file size limit of the process
Additional information: xxxxx
Additional information: yyyyy
Oracle8.1.7對於開啟資料庫會執行很嚴格的在作業系統的上的ULIMIT的檢查，如果檔案大小的限制不夠大，則資料庫就會打不開，出現以上的錯誤。因此就要增大ULIMIT:
ULIMIT -f ；
四．在移植過程中出現ORA-01157的錯誤
1．如果使用移植工具把Oracle7資料庫升級到Oracle8i資料庫，，當執行資料庫轉換的時候有可能會出現以下的錯誤：
ORA-1157 cannot identify datafile - file not found
ORA-1110 datafile :
移植工具首先使用Oracle7的控制檔案去建立一個CONVERT.ORA檔案，當增加一個新的表空間或者新的資料檔案如果新增資料檔案沒有包含全路徑，導致在CONVERT.ORA檔案中就沒有資料檔案路徑正確的指向。
解決方法一是要修改%Oracle_home%rdbmsxxconvert.ora下的CONVERT.ORA檔案中的資料檔案的路徑為正確的路徑，然後重新執行資料庫轉換。
解決方法二是先用備份恢復Oracle7的資料庫，然後重新建立控制檔案，修改資料檔案的路徑為正確的路徑，然後重新執行移植過程。
2．使用移植工具把資料庫Oracle7.3.X移植到Oracle8.1.X，可能會出現以下錯誤：
ORA-01157: cannot identify/lock data file 2 - see DBWR tracefile
ORA-01110: data file 2: '/oradata/V734/users01.dbf'
ORA-27046: file size is not a multiple of logical block size
Additional information:1
一般是資料檔案從裸裝置dd到檔案系統中，資料檔案的大小不是嚴格的Oracle Block Size的整數倍造成的。例如：
file size = 839911424 bytes
Oracle block size = 8092 bytes
解決方法一是把資料檔案RESIZE到一個Oracle Block Size的整數倍：
ALTER DATABASE DATAFILE '' RESIZE ；
- the integer should be a multiple of 8 in our example
解決方法二：
1） 使用dbfsize命令去獲取資料檔案的在資料庫中的大小：
dbfsize
2） 檢視資料檔案在作業系統上的大小：
ls -lt
3） 使用MOD函式對比1）和2）的值，得出餘數。
4） 確定資料庫已經關閉了，然後使用dd命令。
例如：
作業系統上的檔案大小是2097203200 bytes，使用dbfsize得出的結果是511744 4096 byte blocks，那麼使用以下命令：
dd if=bs=4096 count=511745
NB: count= 511744 + 1 (1 for recovering from this problem)
mv to
5） startup nomount
alter database convert；
五．其他一些可能產生ORA-01157錯誤的原因
1．控制檔案的突然中斷引起ORA-01157的錯誤。
A．一種可能的原因是在控制檔案中的檔名的結尾處有一個空格。
可以使用'ALTER DATABASE BACKUP CONTROLFILE TO TRACE'命令，然後在初始化引數user_dump_dest所指向的目錄下面查詢相應的TRACE檔案，檢視控制檔案的內容。例如：
'/home/d/Oracle/oradata/ecn/rdx02.dbf ' <-- corrupt
'/home/d/Oracle/oradata/ecn/rdx02.dbf' <-- non-corrupt
這種情況下用好的控制檔案代替壞了的控制檔案，並修改初始化引數檔案中的CONTROL_FILES引數，去掉壞了的控制檔案。如果所有的控制檔案都損壞了，那就需要重建控制檔案了。
重建控制檔案的方法：
1） 以SYS使用者登陸，執行
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
2） 生成的TRACE檔案在USER_DUMP_DEST的目錄下，然後檢視一下USER_DUMP_DEST的具體目錄路徑：
SELECT VALUE FROM V$PARAMETER WHERE NAME=’USER_DUMP_DEST’；
或者SHOW PARAMETER USER_DUMP_DEST；
3） 找出相應的TRACE檔案，最簡單的找正確的TRACE檔案的方法是看TRACE檔案的建立時間，然後修改TRACE檔案儲存成一個SQL指令碼，例如：
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 'D:ORACLEORADATAORCLREDO01.LOG' SIZE 1M,
GROUP 2 'D:ORACLEORADATAORCLREDO02.LOG' SIZE 1M,
GROUP 3 'D:ORACLEORADATAORCLREDO03.LOG' SIZE 1M
DATAFILE
'D:ORACLEORADATAORCLSYSTEM01.DBF',
'D:ORACLEORADATAORCLUNDOTBS01.DBF',
'D:ORACLEORADATAORCLOEM_REPOSITORY.DBF'
CHARACTER SET ZHS16GBK
；
4） 關閉資料庫：
SHUTDOWN IMMEDIATE；
5） 對資料庫做一個全庫的冷備份。
6） 利用作業系統命令將原來的控制檔案移走。
7） 在SQLPLUS中以SYS使用者執行剛剛儲存的那個指令碼。
8） 開啟資料庫。
2．在STANDBY方式下，如果主資料庫增加了表空間或者資料檔案，而從資料庫中沒有手工增加的話也會出現ORA-01157的錯誤。
3．RMAN恢復會在ALERT.LOG中產生‘FAKE’引起ORA-01157的錯誤。
在RMAN的恢復操作中，在ALERT.LOG中會產生以下的錯誤：
ORA-01157: cannot identify/lock data file N - see DBWR trace file
ORA-01110: data file N: ''
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
產生這種錯誤的原因主要是因為在RMAN恢復之前資料檔案已經被刪除
一．錯誤描述
ORA-1157, "cannot identify/lock data file %s - see DBWR trace file"
引起的原因：
因為資料檔案已經在被使用了從而導致資料庫的後臺程式不能找到相應的資料檔案或者不能鎖定相應的資料檔案，這樣資料庫將禁止訪問這些資料檔案而其他的資料檔案則沒有影響。伴隨這個錯誤作業系統將會提示是哪個資料檔案不能被識別。
ORA-01157錯誤一般和ORA-01110錯誤一起出現，往往還有作業系統級別上的錯誤，例如ORA-07360，同時一個DBWR的trace檔案會在background_dump_dest的目錄下生成。例如，在Solaris的平臺上，會有如下的錯誤資訊顯示：
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/export/home/Oracle/oradata/817/users01.dbf'
然後檢視DBWR的trace檔案內容，會有如下的內容：
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/export/home /Oracle/oradata/817/users01.dbf'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
下面就幾個容易產生ORA-1157錯誤的方面詳細談談：
二． 通常引起ORA-1157錯誤的原因和解決方法
如果你是使用Oracle9i，就用SQLPLUS代替SVRMGRL執行以下的命令。
1． 資料檔案存在，但是Oracle認不到它
這種情況可能是在作業系統級上資料檔案被重新命名了或者移動到了一個新的分割槽或者位置，這種情況比較簡單，只是需要將資料檔案恢復成原始的資料檔名字或者重新命名資料檔案到一個新的位置/目錄就可以解決問題了。
重新命名資料檔案到一個新的位置/目錄的方法：
A. 資料庫是開啟狀態的
1）檢視那個資料檔案所在的表空間還包含有哪些資料檔案，執行以下查詢：
SELECT FILE_NAME, STATUS FROM DBA_DATA_FILES
WHERE TABLESPACE_NAME = ''；
2）確定所有資料檔案的狀態都是可用的。
3）把表空間變成只讀表空間：
ALTER TABLESPACE READ ONLY；
4）確定在資料字典中表空間是顯示為只讀的：
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = ''；
TABLESPACE_NAME STATUS
------------------------------ ---------
READ ONLY
5）用作業系統命令複製資料檔案到一個新的位置，複製完成後把整個表空間
OFFLINE，這個時候使用者是不能訪問這個表空間的：
ALTER TABLESPACE OFFLINE；
6）重新命名這個資料檔案到一個新的位置了，這個操作會自動的更新控制檔案中的內容：
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；
7）ONLINE這個表空間：
ALTER TABLESPACE YOUR_TABLESPACE_NAME ONLINE；
8）把這個表空間置成可讀寫的狀態：
ALTER TABLESPACE YOUR_TABLESPACE_NAME READ WRITE；
9）在作業系統級上刪除原來舊的資料檔案。
B．資料庫是關閉狀態的
1） 先正常關閉資料庫。
2） 用作業系統命令複製資料檔案到一個新的位置。
3） MOUNT資料庫，這樣將讀取控制檔案，但是不會讀取資料檔案：
STARTUP MOUNT
4) 重新命名這個資料檔案到一個新的位置了，這個操作會自動的更新控制檔案中的內容：
ALTER DATABASE RENAME FILE
'/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF'
TO
'/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'；
5） 開啟資料庫：
ALTER DATABASE OPEN；
2． 資料檔案不存在或者對於Oracle來說是不可用的
資料檔案被物理的移走了或者損壞導致Oracle不能再認到了，例如資料檔案被截斷或者覆蓋了，一般會出現ORA-27046、ORA-1157的錯誤提示：
ORA-27046: file size is not a multiple of logical block size
這種情況下可以有兩種選擇去解決問題：
A． 重建資料檔案所屬的那個表空間
這種方法比較適用於USERS、TEMP、INDEX表空間，如果資料庫是正常關閉的，也就是說回滾段中沒有啟用的表空間事務,也推薦使用這種方法。如果是SYSTEM表空間，則要重建資料庫了。
具體步驟如下：
1） MOUNT資料庫：
STARTUP MOUNT PFILE=''；
2） OFFLINE DROP資料檔案：
ALTER DATABASE DATAFILE '' OFFLINE DROP；
3） 開啟資料庫：
ALTER DATABASE OPEN；
4） 刪除表空間：
DROP TABLESPACE INCLUDING CONTENTS；
5） 重建表空間：
CREATE TABLESPACE DATAFILE
' SIZE ；
6） 重建表空間中所有以前存在的物件:可以使用以前建立物件的指令碼或者利用最近可用的EXPORT DUMP來重建以前存在的物件。
B．用正常的恢復過程去恢復資料檔案
這種方法比較適用於只讀表空間或者那種不能用重建表空間的方法的USERS和INDEX表空間。如果是回滾段表空間，那必須要求資料庫是正常關閉的才能使用這個方法。如果是SYSTEM表空間，並且備份和所有的歸檔日誌都全的情況下，強烈建議使用這種方法去恢復的，但是如果是非歸檔方式，則就只能利用當前所有的聯機日誌進行恢復了。
在很多的情況下，重建表空間是不可能的或者是非常費時費力的，因此，從備份和利用歸檔日誌恢復資料檔案是一種比較好的方法，尤其是對於只讀表空間來說，因為沒有資料的寫入和更改，因此直接用備份來恢復是最快最省事的。
具體步驟如下：
1） 從備份中恢復丟失或者損壞的資料檔案。
2） MOUNT資料庫：
STARTUP MOUNT PFILE=''；
3） 執行以下的查詢：
SELECT V1.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#
FROM V$LOG V1, V$LOGFILE V2
WHERE V1.GROUP# = V2.GROUP#；
這個查詢將列出所有聯機重做日誌以及它們所代表的SEQUENCE和FIRST CHANGE NUMBER.
4） 如果資料庫是非歸檔狀態下的，執行以下的查詢：
SELECT FILE#, CHANGE# FROM V$RECOVER_FILE；
如果CHANGE#大於最小的聯機重做日誌檔案的FIRST_CHANGE#，那麼資料檔案可以被恢復，記住恢復資料檔案的時候要應用所有的聯機重做日誌檔案，然後到第5步。
如果CHANGE#小於最小的聯機重做日誌檔案的FIRST_CHANGE#，那麼這個資料檔案將不能被恢復了，那麼只能從最近的資料庫全備份恢復或者重建這個資料檔案所屬的表空間了。
5） 恢復資料檔案：
RECOVER DATAFILE ''；
6） 確認所有的歸檔日誌都被應用了直至出現"Media recovery complete"的提示資訊，如果Oracle提示有一個不存在的歸檔日誌檔案，那麼就可能要應用所有的聯機重做日誌檔案來恢復直至出現"Media recovery complete"的提示資訊。
7） 開啟資料庫：
ALTER DATABASE OPEN；
3． 資料庫臨時表空間的資料檔案的丟失
當資料庫的臨時表空間的資料檔案丟失也會引起ORA-01157的錯誤。因為資料庫對臨時表空間的資料檔案不會發生檢查點，所以這個時候資料庫照樣能夠開啟。這種情況下的解決方法是邏輯上刪除臨時表空間的資料檔案，並且重新增加一個新的臨時表空間的資料檔案。
例如：
SELECT * FROM DBA_OBJECTS ORDER BY OBJECT_NAME；
select * from dba_objects order by object_name；
* ERROR at line 1:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/Oracle/oradata/temp01.dbf'
ALTER DATABASE TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ DROP；
SELECT TABLESPACE_NAME,FILE_NAME FROM DBA_TEMP_FILES；
ALTER TABLESPACE TEMP ADD TEMPFILE ‘/Oracle/oradata/temp01.dbf‘ SIZE 100M；
三．由於作業系統的問題或者第三方軟體的問題導致ORA-01157錯誤
1． 當使用vxfddstat去訪問快速I/O或者其它的應用，會獲得"Cannot open file"的錯誤，而Oracle會返回如下的錯誤：
ORA-01157: cannot identify data file 1 - file not found
ORA-01110: data file 1: ''
這個時候使用者應該去聯絡Veritas的技術支援，技術支援網站網址為。
2． 在HP-UNIX的機器上，如果系統核心引數nflock設定不是足夠大的時候，這樣可能會使Oracle不能鎖定所需要的資料檔案而導致錯誤：
ORA-27086: skgfglk: unable to lock file - already in use
或者錯誤：
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-0110: data file 4: '/Oracle/oradata/user01.dbf'
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 2
或者錯誤：
ORA-07445: exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]
ORA-01110: data file %s: '%s'
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01115: IO error reading block from file %s (block # %s)
ORA-27041: unable to open file
HP-UX Error: 23: File table overflow
Additional information: 3
解決這個問題的方法是增大相關的核心引數：（建議以下的配置）
nproc 4096 Max Number of Processes
nfile 63488 Max Number of Open Files
nflocks 4096 Max Number of File Locks
3． 如果Oracle需要的資料檔案被其他程式鎖定的條件下也會導致這個錯誤。
例如：備份軟體將可能鎖定要備份的資料檔案
在WINDOWS上可能會有如下的錯誤：
ORA-01157: signalled during alter database open
ORA-01157: can not identify datafile
ORA-01110: datafile path and filename of datafile
ORA-27047: Unable to read header of file
OSD-04006: Read file failure
Error 33: process can not access file
作業系統錯誤33是一個error_lock_violation，表明一部分資料檔案被WINDOWS的其他程式鎖定了。
或者錯誤：
ORA-1157 - cannot identify datafile - file not found
ORA-1110 - datafile :
ORA-9202 - sfifi: error identifying file
OSD-4006(OS 203) - The System could not find the
environment option that was entered
在ALERT檔案中將會同時出現以下的錯誤：
ORA-1115 - IO error reading block from file %s (block # %s)
ORA-1110 - datafile :
ORA-9206 - sfrfb: error reading from file
OSD-4006(OS 203) - The System Could not find the environment
option that was entered
或者錯誤：
ORA-1242 - data file suffered media failure: database in NOARCHIVELOG mode
ORA-1114 - IO error writing block to file block #
ORA-9205 - sfqio: error reading or writing to disk
OSD-4016(OS 33) - The process cannot access the file because another
process has locked a portion of the file
另外還可能會出現以下錯誤：
KCF: write/open error dba=0x703473d block=0x3473d online=1
file=7 E:Oracledatagreccrecind2.dbf
error=9211 txt: 'OSD-4008 : WriteFile error (OS 203) - The System
Could not find the environment option that was entered
某些情況下ALERT檔案中會出現：
Instance terminating due to error 1110.
Instance terminated by PID=XXX
或者：
TERMINATING INSTANCE DUE TO ERROR 472
ORA 472 - PMON process terminated with error
在WINDOWS的事件檢視器中可以看到以下事件：
23 Error ReadFile() failure
25 Error WriteFile() failure
如果這是個冷備份，那就要等冷備份完成後啟動資料庫或者結束冷備份啟動資料庫。對於備份軟體，最好都配置成不要鎖定開啟的資料檔案的備份方式。
這種情況的解決方法是手工的清除在資料檔案上的鎖：
1） 執行ps -ef | grep ，查出在資料檔案上已經存在的程式。
2） 執行kill –9 程式ID
4． 使用WINDOWS的FILE MANAGER複製Oracle的資料檔案的時候也會引起ORA-01157的錯誤，例如檔名大於通常用的8.3格式，如果檔名大於8個字元或者你的副檔名大於3個字元就會引起這個錯誤。要避免這個錯誤，在WINDOWS下複製檔案不要用FILE MANAGER，最好使用瀏覽器去複製檔案，如果已經使用FILE MANAGER，那麼對於長檔名的檔案會自動加上一個～，這樣要重新命名複製的檔案為原來的檔名字。
5． 使用網路應用工具也可能會引起ORA-01157的錯誤。
在一些網路工具的使用操作中要求對資料檔案進行加鎖，如果由於例項錯誤或者主機的問題可能會導致這些鎖會一直的存在，這種情況下需要系統管理員手工的去釋放這些鎖。
6． 如果Oracle的資料檔案被一個其他的使用者恢復也可能引起ORA-01157的錯誤。
在Oracle的資料檔案被恢復之後，Oracle資料庫認不到恢復後的資料檔案，因此錯誤ORA-1157 (cannot identify datafile - file not found)就可能發生：
???? 資料檔案在作業系統上是否存在
???? SELECT * FROM V$DATAFILE檢視資料檔案的正確路徑
???? ALTER SYSTEM CHECK DATAFILE是否成功
???? 使用BACKUP CONTROLFILE TO TRACE檢視資料檔案的正確路徑
一般出現這種問題有可能是作業系統上的許可權問題，首先檢視資料檔案的許可權，當資料檔案被其他使用者恢復的時候可能許可權就變了，可能Oracle使用者就不能訪問了，這樣就要對恢復後的資料檔案修改許可權和屬主。
7． ULIMIT設定的值不夠大也可能會引起ORA-01157的錯誤。
在DBWR的跟蹤檔案中會有ORA-1157和ORA-27092的錯誤：
ORA-01157: cannot identify/lock data file N - see DBWR trace file
ORA-01110: data file 1: ''
ORA-27092: skgfofi: size of file exceeds file size limit of the process
Additional information: xxxxx
Additional information: yyyyy
Oracle8.1.7對於開啟資料庫會執行很嚴格的在作業系統的上的ULIMIT的檢查，如果檔案大小的限制不夠大，則資料庫就會打不開，出現以上的錯誤。因此就要增大ULIMIT:
ULIMIT -f ；
四．在移植過程中出現ORA-01157的錯誤
1．如果使用移植工具把Oracle7資料庫升級到Oracle8i資料庫，，當執行資料庫轉換的時候有可能會出現以下的錯誤：
ORA-1157 cannot identify datafile - file not found
ORA-1110 datafile :
移植工具首先使用Oracle7的控制檔案去建立一個CONVERT.ORA檔案，當增加一個新的表空間或者新的資料檔案如果新增資料檔案沒有包含全路徑，導致在CONVERT.ORA檔案中就沒有資料檔案路徑正確的指向。
解決方法一是要修改%Oracle_home%rdbmsxxconvert.ora下的CONVERT.ORA檔案中的資料檔案的路徑為正確的路徑，然後重新執行資料庫轉換。
解決方法二是先用備份恢復Oracle7的資料庫，然後重新建立控制檔案，修改資料檔案的路徑為正確的路徑，然後重新執行移植過程。
2．使用移植工具把資料庫Oracle7.3.X移植到Oracle8.1.X，可能會出現以下錯誤：
ORA-01157: cannot identify/lock data file 2 - see DBWR tracefile
ORA-01110: data file 2: '/oradata/V734/users01.dbf'
ORA-27046: file size is not a multiple of logical block size
Additional information:1
一般是資料檔案從裸裝置dd到檔案系統中，資料檔案的大小不是嚴格的Oracle Block Size的整數倍造成的。例如：
file size = 839911424 bytes
Oracle block size = 8092 bytes
解決方法一是把資料檔案RESIZE到一個Oracle Block Size的整數倍：
ALTER DATABASE DATAFILE '' RESIZE ；
- the integer should be a multiple of 8 in our example
解決方法二：
1） 使用dbfsize命令去獲取資料檔案的在資料庫中的大小：
dbfsize
2） 檢視資料檔案在作業系統上的大小：
ls -lt
3） 使用MOD函式對比1）和2）的值，得出餘數。
4） 確定資料庫已經關閉了，然後使用dd命令。
例如：
作業系統上的檔案大小是2097203200 bytes，使用dbfsize得出的結果是511744 4096 byte blocks，那麼使用以下命令：
dd if=bs=4096 count=511745
NB: count= 511744 + 1 (1 for recovering from this problem)
mv to
5） startup nomount
alter database convert；
五．其他一些可能產生ORA-01157錯誤的原因
1．控制檔案的突然中斷引起ORA-01157的錯誤。
A．一種可能的原因是在控制檔案中的檔名的結尾處有一個空格。
可以使用'ALTER DATABASE BACKUP CONTROLFILE TO TRACE'命令，然後在初始化引數user_dump_dest所指向的目錄下面查詢相應的TRACE檔案，檢視控制檔案的內容。例如：
'/home/d/Oracle/oradata/ecn/rdx02.dbf ' <-- corrupt
'/home/d/Oracle/oradata/ecn/rdx02.dbf' <-- non-corrupt
這種情況下用好的控制檔案代替壞了的控制檔案，並修改初始化引數檔案中的CONTROL_FILES引數，去掉壞了的控制檔案。如果所有的控制檔案都損壞了，那就需要重建控制檔案了。
重建控制檔案的方法：
1） 以SYS使用者登陸，執行
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
2） 生成的TRACE檔案在USER_DUMP_DEST的目錄下，然後檢視一下USER_DUMP_DEST的具體目錄路徑：
SELECT VALUE FROM V$PARAMETER WHERE NAME=’USER_DUMP_DEST’；
或者SHOW PARAMETER USER_DUMP_DEST；
3） 找出相應的TRACE檔案，最簡單的找正確的TRACE檔案的方法是看TRACE檔案的建立時間，然後修改TRACE檔案儲存成一個SQL指令碼，例如：
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 453
LOGFILE
GROUP 1 'D:ORACLEORADATAORCLREDO01.LOG' SIZE 1M,
GROUP 2 'D:ORACLEORADATAORCLREDO02.LOG' SIZE 1M,
GROUP 3 'D:ORACLEORADATAORCLREDO03.LOG' SIZE 1M
DATAFILE
'D:ORACLEORADATAORCLSYSTEM01.DBF',
'D:ORACLEORADATAORCLUNDOTBS01.DBF',
'D:ORACLEORADATAORCLOEM_REPOSITORY.DBF'
CHARACTER SET ZHS16GBK
；
4） 關閉資料庫：
SHUTDOWN IMMEDIATE；
5） 對資料庫做一個全庫的冷備份。
6） 利用作業系統命令將原來的控制檔案移走。
7） 在SQLPLUS中以SYS使用者執行剛剛儲存的那個指令碼。
8） 開啟資料庫。
2．在STANDBY方式下，如果主資料庫增加了表空間或者資料檔案，而從資料庫中沒有手工增加的話也會出現ORA-01157的錯誤。
3．RMAN恢復會在ALERT.LOG中產生‘FAKE’引起ORA-01157的錯誤。
在RMAN的恢復操作中，在ALERT.LOG中會產生以下的錯誤：
ORA-01157: cannot identify/lock data file N - see DBWR trace file
ORA-01110: data file N: ''
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
產生這種錯誤的原因主要是因為在RMAN恢復之前資料檔案已經被刪除
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15498/viewspace-2089477/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- ORA-01157錯誤解決(zt)
- Ocelot錯誤解決
- VIM 常用錯誤解決
- sqldeveloper for windows 錯誤解決SQLDeveloperWindows
- vsftpd 錯誤：530 and 500 錯誤解決方法FTP
- latex 錯誤以及解決方案
- ora-27504錯誤解決
- Datastore error in 'dirbdb'錯誤解決ASTError
- ORA-27054 錯誤解決
- mysql與php錯誤解決MySqlPHP
- mysql錯誤解決總結MySql
- PbootCMS 404 錯誤解決方法boot
- 【故障解決】OGG-00446 錯誤解決
- dbfread報錯ValueError錯誤解決方法Error
- 【故障解決】ORA-06502錯誤解決
- HTTP 錯誤 500.19- Internal Server Error 錯誤解決方法HTTPServerError
- dns錯誤怎麼辦 dns錯誤的解決辦法DNS
- HTTP代理錯誤怎麼解決？HTTP
- undefined reference to錯誤的解決方法Undefined
- SAXParseException的錯誤解決之二Exception
- PHP curl error 60 錯誤解決PHPError
- ORA-04091錯誤解決
- ORA-3136 錯誤解決 .
- [Windows] 解決 COM Surrogate 錯誤提示Windows
- AFNetworkingErrorDomain 錯誤解決方法ErrorAI
- [Flashback]ORA-38760錯誤解決
- EXP-00091錯誤解決
- virtualbox 錯誤解決記錄
- INS-40904 錯誤解決
- Mac下面svn錯誤資訊解決Mac
- PHP錯誤“Thisfilehasexpired”的解決方法PHP
- SAP錯誤提示解決辦法
- ClamAV無法更新錯誤解決
- clamd socket找不到錯誤解決
- ora-00604錯誤解決
- Linux下錯誤解決方案Linux
- steam磁碟寫入錯誤怎麼解決 steam磁碟寫入錯誤解決方法大全
- 解決MySQL server has gone away錯誤的解決方案MySqlServerGo