這是我們為大家提供的一篇介紹如何解決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
4)確定在數據字典中表空間是顯示為只讀的:
SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = '
TABLESPACE_NAME STATUS
------------------------------ ---------
5)用操作系統命令拷貝數據文件到一個新的位置,拷貝完成後把整個表空間
OFFLINE,這個時候用戶是不能訪問這個表空間的:
ALTER TABLESPACE
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 '
3) 打開數據庫:
ALTER DATABASE OPEN;
4) 刪除表空間:
DROP TABLESPACE INCLUDING CONTENTS;
5) 重建表空間:
CREATE TABLESPACE DATAFILE
'
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;