linux数据库宕机,数据库突然宕机无法open的问题及解决

测试的数据库有一天突然宕机，然后无法正常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/，如需转载，请注明出处，否则将追究法律责任。