oracle誤刪除表空間的資料檔案

事故原因:

1.由於誤操作用hp unix 命令 rm -f datafilename 刪除表空間的資料檔案

2.alter tablespace tablespacenaem drop datafile datafile ;

3.drop tablespace tablespacename including content and datafiles;

上述兩個步驟我用了近三個小時都沒有執行完，最後導致資料庫當機。下面把我當時啟動資料的後臺頁面展現給大家，為以後出現同樣的問題，提供一個參照的作用.

SP2-0734: unknown command beginning "sqlplus /n..." - rest of line ignored.
SQL> conn sys/passwd as sysdba;
Connected to an idle instance.
SQL> startup
ORACLE instance started.

Total System Global Area 3.2212E 10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E 10 bytes
Redo Buffers               14659584 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 3.2212E 10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E 10 bytes
Redo Buffers               14659584 bytes
Database mounted.
SQL> recover datafile tbs_db_bas2.dbf;
ORA-02236: invalid file name

SQL> recover datafile '/data/tbs_db_bas2.dbf';
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> revover database;
SP2-0734: unknown command beginning "revover da..." - rest of line ignored.
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> shutdown immediat;
SP2-0717: illegal SHUTDOWN option
SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 3.2212E 10 bytes
Fixed Size                  2115136 bytes
Variable Size            3204450752 bytes
Database Buffers         2.8991E 10 bytes
Redo Buffers               14659584 bytes
Database mounted.
SQL> alter database datafile '/data/tbs_db_bas1.dbf' offline drop;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: '/data/tbs_db_bas2.dbf'

SQL> alter database datafile '/data/tbs_db_bas2.dbf' offline drop;

Database altered.

SQL> alter database open;

Database altered.

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
lsnrctl

LSNRCTL for HPUX: Version 10.2.0.4.0 - Production on 03-MAY-2010 20:13:51

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> stop
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hljww)(PORT=1521)))
The command completed successfully
LSNRCTL> start
Starting /oracle/oracle/OraHome_1/bin/tnslsnr: please wait...

TNSLSNR for HPUX: Version 10.2.0.4.0 - Production
System parameter file is /oracle/oracle/OraHome_1/network/admin/listener.ora
Log messages written to /oracle/oracle/OraHome_1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hljww)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hljww)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for HPUX: Version 10.2.0.4.0 - Production
Start Date                03-MAY-2010 20:14:08
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /oracle/oracle/OraHome_1/network/admin/listener.ora
Listener Log File         /oracle/oracle/OraHome_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hljww)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "hljwxwl" has 1 instance(s).
  Instance "hljwxwl", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

-- 總結上述報錯原因是由於我的資料檔案沒有在oracle內部進行刪除導致資料庫重新啟動時找不到相應的資料檔案，報上述錯誤，所以我建議大家遇到問題時，要沉著，冷靜，不要亂，做好備份工作，特別是遇到錯誤時我們上網查一下oracle錯誤，進行相應的處理。下面我把這次我用到的文件分享給大家，其中粉紅色字型為本次用到的解決方案。

ORA-1157, "cannot identify/lock data file %s - see DBWR trace file"

引起的原因：

因為資料檔案已經在被使用了從而導致資料庫的後臺程式不能找到相應的資料檔案或者不能鎖定相應的資料檔案，這樣資料庫將禁止訪問這些資料檔案而其他的資料檔案則沒有影響。伴隨這個錯誤作業系統將會提示是哪個資料檔案不能被識別。

ORA-01157錯誤一般和ORA-01110錯誤一起出現，往往還有作業系統級別上的錯誤，例如ORA-07360，同時一個DBWR的trace檔案會在background_dump_dest的目錄下生成。例如，在Solaris的平臺上，會有如下的錯誤資訊顯示：
more..
less..
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'