数据库突然宕机的问题及分析
昨天晚上，某个环境的数据库在做一个压力测试的时候突然宕机了。这个问题比较急。马上查看日志文件。
看到了如下的一段，报了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 <
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 <
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的。
本文名称：数据库突然宕机的问题及分析
网站网址：http://scjbc.cn/article/jhoogj.html
看到了如下的一段，报了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 <
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 <
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的。
本文名称：数据库突然宕机的问题及分析
网站网址：http://scjbc.cn/article/jhoogj.html
