資料庫突然當機的問題及分析

昨天晚上，某個環境的資料庫在做一個壓力測試的時候突然當機了。這個問題比較急。馬上檢視日誌檔案。
看到了如下的一段，報了os級的linux錯誤。提示沒有空間了。

Fri Mar 14 19:16:47 2014
Archived Log entry 192 added for thread 1 sequence 192 ID 0x1ed7a02c dest 1:
Fri Mar 14 19:39:24 2014
Incremental checkpoint up to RBA [0xc0.2aa5fb.0], current log tail at RBA [0xc1.5d29f.0]
Fri Mar 14 19:46:37 2014
Completed checkpoint up to RBA [0xc1.2.10], SCN: 252702724
Fri Mar 14 20:09:32 2014
Incremental checkpoint up to RBA [0xc1.5d36a.0], current log tail at RBA [0xc1.b8498.0]
Fri Mar 14 20:13:15 2014
KCF: read, write or open error, block=0xa6b82 online=1
        file=1 '/TEST1/db05/oradata/PRDTEST1/TEMP_1.dbf'
        error=27061 txt: 'Linux-x86_64 Error: 28: No space left on device
Additional information: -1
Additional information: 8192'
Errors in file /test01/oracle/adm/PRDTEST1/diag/rdbms/prdTEST1/PRDTEST1/trace/PRDTEST1_dbw7_19235.trc:
Errors in file /test01/oracle/adm/PRDTEST1/diag/rdbms/prdTEST1/PRDTEST1/trace/PRDTEST1_dbw7_19235.trc:
ORA-63999: data file suffered media failure
ORA-01114: IO error writing block to file 5001 (block # 682882)
ORA-01110: data file 5001: '/TEST1/db05/oradata/PRDTEST1/TEMP_1.dbf'
ORA-27061: waiting for async I/Os failed
Linux-x86_64 Error: 28: No space left on device
Additional information: -1
Additional information: 8192
DBW7 (ospid: 19235): terminating the instance due to error 63999
Fri Mar 14 20:13:16 2014
System state dump requested by (instance=1, osid=19235 (DBW7)), summary=[abnormal instance termination].
System State dumped to trace file /test01/oracle/adm/PRDTEST1/diag/rdbms/prdTEST1/PRDTEST1/trace/PRDTEST1_diag_19213.trc
Termination issued to instance processes. Waiting for the processes to exit
Fri Mar 14 20:13:31 2014
Instance termination failed to kill one or more processes
Instance terminated by DBW7, pid = 19235
Fri Mar 14 22:55:44 2014
Starting ORACLE instance (normal)

馬上開始檢視檔案系統的空間，確實是不夠了。緊急resize了下檔案，把庫先起來，然後再協調系統的資源了。
問題雖然馬上解決了。但是對於檔案寫入（報錯非同步io)的情況，資料庫例項會同然down掉。確實是一件很敏感的事情。
在metalink上查詢有一個類似的錯誤，但是是基於NAS環境的，那個Unix環境做了一些系統變更導致了這個錯誤和這個問題還是有一些不同。（文件 ID 1557694.1）
我在想對於如果資料檔案寫入失敗，有沒有一些措施來控制，保證不會把庫給down掉。發現在11.2.0.2版本之後，發現了一個隱含引數（_datafile_write_errors_crash_instance）
檢視隱含引數的指令碼如下。

set linesize 132 column name format a30 column value format a25 
select
x.ksppinm name,
y.ksppstvl value,
y.ksppstdf isdefault, 
decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod, 
decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj 
from sys.x$ksppi x, sys.x$ksppcv y 
where x.inst_id = userenv('Instance') 
and y.inst_id = userenv('Instance') 
and x.indx = y.indx 
and x.ksppinm like '%_%' 
order by translate(x.ksppinm, ' _', ' ') 
/


預設這個引數_datafile_write_errors_crash_instance的值是true的。
oracle給出的解釋如下,還有一個相關的bug（文件 ID 7691270.8）已經在11.2.0.2做了修復。
If _datafile_write_errors_crash_instance = TRUE (default) then
  any write to a datafile which fails due to an IO error causes 
  an instance crash. 


 If _datafile_write_errors_crash_instance = FALSE then the behaviour
  reverts to the previous behaviour (before this fix) such that
  a write error to a datafile offlines the file (provided the DB is
  in archivelog mode and the file is not in SYSTEM tablespace in 
  which case the instance is aborted)
簡單的測試
大家可能想如果表空間不夠了，資料檔案空間不夠了，資料庫是不是也會down掉。我簡單在本地做了測試來看在並行插入的時候如果檔案空間不夠會不會把庫down掉。但是要模擬資料檔案的錯誤，可能需要藉助bbed等工具來模擬了。
step 1.首先為了先把隱含引數設定為預設值true
alter system set "_datafile_write_errors_crash_instance"=TRUE;
step 2.然後建立了一個dummy檔案，保證檔案系統中的空間只剩下很少的一部分。
dd if=/dev/zero of=/u02/ora11g/hello.txt bs=1000M count=1
-rw-r--r--  1 ora11g dba    1048576000 Mar 15 04:09 hello.txt


/dev/sdb2             7.6G  7.2G   45M 100% /u02
只剩下很小的一部分空間了，45M的樣子。
step 3.建立兩個個表空間。讓資料檔案自動增長。
SQL> create tablespace test_data1 datafile '/u02/ora11g/testdata1.dbf' size 2M autoextend on;
Tablespace created.

SQL> create tablespace test_data2 datafile '/u02/ora11g/testdata2.dbf' size 2M autoextend on;
Tablespace created.

step 4:建立兩個表屬於不同的表空間
SQL> create table test1 tablespace test_data1 as select *from cat;
Table created.

SQL> create table test2 tablespace test_data2 as select *from user_objects;
Table created.

step 5:簡單核查一下表裡的資料。保證資料量在可控範圍內。
SQL> select count(*)from test1;
  COUNT(*)
----------
         4
SQL> select count(*)from test2;
  COUNT(*)
----------
         5


step 6:然後寫了如下的3個指令碼來往兩個表裡分別不斷的插入和commit
指令碼1 a.sh
sqlplus test/test <<EOF
begin
for i in 1..10000 loop
insert into test1 select *from test1 where rownum<5;
commit;
end loop;
end;
/
EOF
exit

指令碼2 b.sh
sqlplus test/test <<EOF
begin
for i in 1..10000 loop
insert into test2 select *from test2 where rownum<10;
commit;
end loop;
end;
/
EOF
exit

指令碼3 c.sh ，可以基本保證兩個執行是並行的。
ksh a.sh &
ksh b.sh &

step 7,執行指令碼3以後檢視日誌內容
馬上看到alert裡面馬上又瞭如下的資訊
Sat Mar 15 07:40:22 2014
ORA-1653: unable to extend table TEST.TEST2 by 128 in                 tablespace TEST_DATA2 
ORA-1653: unable to extend table TEST.TEST2 by 128 in                 tablespace TEST_DATA2 
由以上的簡單測試可以看出表空間不夠的時候，例項還是能夠保證open的。