資料庫突然當機無法open的問題及解決

jeanron100發表於2014-03-04
測試的資料庫有一天突然當機,然後無法正常open了,這個問題雖然過去了一段時間,也在這兒總結一把。
從alert日誌中的資訊如下。
Fri Jan 10 16:09:42 2014
Archived Log entry 6837 added for thread 1 sequence 6863 ID 0x19db56aa dest 1:
Fri Jan 10 16:12:59 2014
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_lgwr_2432.trc:
ORA-19502: write error on file "/oravl04/oradata/FETABP2/cntrl_1.dbf", block number 1191 (block size=16384)
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 28: No space left on device
Additional information: -1
Additional information: 131072
LGWR (ospid: 2432): terminating the instance due to error 19502
Fri Jan 10 16:13:01 2014
System state dump requested by (instance=1, osid=2432 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc
Non critical error ORA-48913 caught while writing to trace file "/oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_diag_2422.trc"
Error message: ORA-48913: Writing into trace file failed, file size limit [5242880] reached
Writing to the above trace file is disabled for now on...
Instance terminated by LGWR, pid = 2432
Fri Jan 10 16:32:32 2014
從上可以看到,資料庫遇到了io問題,並且空間也不夠了,直接當機了。

先mount上再說,別直接拿過來就open,可能一些恢復問題讓自己的誤操作弄的更復雜了。如果生產環境,那影響就更大了。需要先做詳細的判斷再動手。

由於這個是測試環境先來演示一下錯誤。

alter database open
Errors in file /oravl01/oracle/adm/FETABP2/diag/rdbms/fetabp2/FETABP2/trace/FETABP2_ora_4780.trc:
ORA-10873: file 1 needs to be either taken out of backup mode or media recovered
ORA-01110: data file 1: '/oravl04/oradata/FETABP2/SYSTEM_1.dbf'
ORA-10873 signalled during: alter database open...
Fri Jan 10 17:02:26 2014

檢視資料庫狀態。
SQL> select status from v$instance;

STATUS
------------
MOUNTED

檢視資料檔案的scn情況
SQL> select file#,checkpoint_change# from v$datafile;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1         1.3605E+13
         2         1.3605E+13
         3         1.3605E+13
         4         1.3605E+13
         5         1.3605E+13
         6         1.3605E+13
         7         1.3605E+13
         8         1.3605E+13
         9         1.3605E+13
        10         1.3605E+13
        11         1.3605E+13

11 rows selected.
顯示不清楚,先格式化再看看。
SQL> col checkpoint_change# format 99999999999999999
SQL> /

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1     13605259062393
         2     13605259062399
         3     13605259062404
         4     13605259062411
         5     13605259062416
         6     13605259062422
         7     13605259062411
         8     13605259062411
         9     13605259062411
        10     13605259062411
        11     13605259062411

11 rows selected.
可以看到有很多不一致。
檢視資料庫檔案頭的scn情況,情況類似。
SQL> select file#,checkpoint_change# from v$datafile_header;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1     13605259062393
         2     13605259062399
         3     13605259062404
         4     13605259062411
         5     13605259062416
         6     13605259062422
         7     13605259062411
         8     13605259062411
         9     13605259062411
        10     13605259062411
        11     13605259062411
如果是這個狀態,可能是有對資料庫做了什麼其他的操作,檢視熱備份的情況
這下揪到問題了。
SQL> select * from v$backup;
     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ---------
         1 ACTIVE             1.3605E+13 08-JAN-14
         2 ACTIVE             1.3605E+13 08-JAN-14
         3 ACTIVE             1.3605E+13 08-JAN-14
         4 ACTIVE             1.3605E+13 08-JAN-14
         5 ACTIVE             1.3605E+13 08-JAN-14
         6 ACTIVE             1.3605E+13 08-JAN-14
         7 ACTIVE             1.3605E+13 08-JAN-14
         8 ACTIVE             1.3605E+13 08-JAN-14
         9 ACTIVE             1.3605E+13 08-JAN-14
        10 ACTIVE             1.3605E+13 08-JAN-14
        11 ACTIVE             1.3605E+13 08-JAN-14

從日誌裡面翻看熱備份的情況,連續好幾天都沒有end backup的命令出現,可見io的那個問題和這個也有一定的關係。
先修復一下。
用下面的sql生成修復語句。
select 'alter tablespace '||name|| ' end backup;'  from v$tablespace where ts# in (select ts# from v$datafile where file# in (select file# from v$backup));
生成的命令如下。
alter tablespace system end backup;
.....

修復了一部分,檢視備份表。可以看到好多狀態都發生了改變。
SQL> select * from v$backup;

     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ---------
         1 NOT ACTIVE         1.3605E+13 08-JAN-14
         2 NOT ACTIVE         1.3605E+13 08-JAN-14
         3 ACTIVE             1.3605E+13 08-JAN-14
         4 NOT ACTIVE         1.3605E+13 08-JAN-14
         5 NOT ACTIVE         1.3605E+13 08-JAN-14
         6 NOT ACTIVE         1.3605E+13 08-JAN-14
         7 NOT ACTIVE         1.3605E+13 08-JAN-14
         8 NOT ACTIVE         1.3605E+13 08-JAN-14
         9 NOT ACTIVE         1.3605E+13 08-JAN-14
        10 NOT ACTIVE         1.3605E+13 08-JAN-14
        11 NOT ACTIVE         1.3605E+13 08-JAN-14
11 rows selected.

修復完成後,可以看到狀態都是not active的了。
SQL> select * from v$backup;

     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ---------
         1 NOT ACTIVE         1.3605E+13 08-JAN-14
         2 NOT ACTIVE         1.3605E+13 08-JAN-14
         3 NOT ACTIVE         1.3605E+13 08-JAN-14
         4 NOT ACTIVE         1.3605E+13 08-JAN-14
         5 NOT ACTIVE         1.3605E+13 08-JAN-14
         6 NOT ACTIVE         1.3605E+13 08-JAN-14
         7 NOT ACTIVE         1.3605E+13 08-JAN-14
         8 NOT ACTIVE         1.3605E+13 08-JAN-14
         9 NOT ACTIVE         1.3605E+13 08-JAN-14
        10 NOT ACTIVE         1.3605E+13 08-JAN-14
        11 NOT ACTIVE         1.3605E+13 08-JAN-14

再次檢視scn的情況。
SQL> select file#,checkpoint_change# from v$datafile
  2  
SQL> /

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1     13607479649688
         2     13607479649688
         3     13607479649688
         4     13607479649688
         5     13607479649688
         6     13607479649688
         7     13607479649688
         8     13607479649688
         9     13607479649688
        10     13607479649688
        11     13607479649688
檢視資料檔案頭的情況。
SQL> select file#,checkpoint_change# from v$datafile_header;
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1     13607479649688
         2     13607479649688
         3     13607479649688
         4     13607479649688
         5     13607479649688
         6     13607479649688
         7     13607479649688
         8     13607479649688
         9     13607479649688
        10     13607479649688
        11     13607479649688
確認沒問題了,開啟資料庫。
SQL> alter database open;

Database altered.



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-1100756/,如需轉載,請註明出處,否則將追究法律責任。

相關文章