如何解決ORA-01157錯誤

如何解決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 = '<YOUR_TABLESPACE_NAME>'；
2）確定所有數據文件的狀態都是可用的。
3）把表空間變成只讀表空間：
ALTER TABLESPACE <YOUR_TABLESPACE_NAME> READ ONLY；
4）確定在數據字典中表空間是顯示為只讀的：
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = '<YOUR_TABLESPACE_NAME>'；
TABLESPACE_NAME STATUS
------------------------------ ---------
<YOUR_TABLESPACE_NAME> READ ONLY
5）用操作系統命令拷貝數據文件到一個新的位置，拷貝完成后把整個表空間
OFFLINE，這個時候用戶是不能訪問這個表空間的：
ALTER TABLESPACE <YOUR_TABLESPACE_NAME> 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='<location_of_pfile>'；
2） OFFLINE DROP數據文件：
ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP；
3） 打開數據庫：
ALTER DATABASE OPEN；
4） 刪除表空間：
DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS；
5） 重建表空間：
CREATE TABLESPACE <tablespace_name> DATAFILE
'<datafile_full_path_name'> SIZE <required_size>；
6） 重建表空間中所有以前存在的對象:可以使用以前創建對象的腳本或者利用最近可用的EXPORT DUMP來重建以前存在的對象。
B．用正常的恢復過程去恢復數據文件
這種方法比較適用于只讀表空間或者那種不能用重建表空間的方法的USERS和INDEX表空間。如果是回滾段表空間，那必須要求數據庫是正常關閉的才能使用這個方法。如果是SYSTEM表空間，并且備份和所有的歸檔日志都全的情況下，強烈建議使用這種方法去恢復的，但是如果是非歸檔方式，則就只能利用當前所有的聯機日志進行恢復了。
在很多的情況下，重建表空間是不可能的或者是非常費時費力的，因此，從備份和利用歸檔日志恢復數據文件是一種比較好的方法，尤其是對于只讀表空間來說，因為沒有數據的寫入和更改，因此直接用備份來恢復是最快最省事的。
具體步驟如下：
1） 從備份中恢復丟失或者損壞的數據文件。
2） MOUNT數據庫：
STARTUP MOUNT PFILE='<location_of_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 '<full_path_file_name>'；
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: '<filename>'
這個時候用戶應該去聯系Veritas的技術支持，技術支持網站網址為http://support.veritas.com/。
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 <datafile id>
ORA-01110: datafile <datafile id> path and filename of datafile
ORA-27047: Unable to read header of file <datafile id>
OSD-04006: Read file failure
Error 33: process can not access file
操作系統錯誤33是一個error_lock_violation，表明一部分數據文件被WINDOWS的其他進程鎖定了。
或者錯誤：
ORA-1157 - cannot identify datafile <name> - file not found
ORA-1110 - datafile <name>: <str>
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 <name>: <str>
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 <name> block # <num>
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 <background process> PID=XXX
或者：
<background process> 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 <SID>，查出在數據文件上已經存在的進程。
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)就可能發生：
&#1048698; 數據文件在操作系統上是否存在
&#1048698; SELECT * FROM V$DATAFILE查看數據文件的正確路徑
&#1048698; ALTER SYSTEM CHECK DATAFILE是否成功
&#1048698; 使用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: '<filename>'
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 <require_size_of_file_in_os_blocks>；
四．在移植過程中出現ORA-01157的錯誤
1．如果使用移植工具把Oracle7數據庫升級到Oracle8i數據庫，，當執行數據庫轉換的時候有可能會出現以下的錯誤：
ORA-1157 cannot identify datafile <name> - file not found
ORA-1110 datafile <name>: <str>
移植工具首先使用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 '<filename>' RESIZE <VALUE IN KB OR MB>；
- the integer should be a multiple of 8 in our example
解決方法二：
1） 使用dbfsize命令去獲取數據文件的在數據庫中的大小：
dbfsize <file_name>
2） 查看數據文件在操作系統上的大小：
ls -lt <file_name>
3） 使用MOD函數對比1）和2）的值，得出余數。
4） 確定數據庫已經關閉了，然后使用dd命令。
例如：
操作系統上的文件大小是2097203200 bytes，使用dbfsize得出的結果是511744 4096 byte blocks，那么使用以下命令：
dd if=<some_name>bs=4096 count=511745
NB: count= 511744 + 1 (1 for recovering from this problem)
mv <some_file> to <file_name>
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: '<filename>'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
產生這種錯誤的原因主要是因為在RMAN恢復之前數據文件已經被刪除

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。