数据库突然宕机无法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.

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-03-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

ORACLE 11g导入9i dump的问题及解决

因为系统迁移,需要将一部分的9i的数据导入11g的库里, 目标库是11.2.0.3.0 64位的环境。 导入dump的时候,有一个比较大的分区表,需要用导入分...

3257
来自专栏杨建荣的学习笔记

备库查询导致的ORA-01110错误及修复(r8笔记第67天)

最近帮助业务部门解决了一个技术问题,因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来,当我看到他们提供的语句,在备 库做了简单的数...

3257
来自专栏散尽浮华

Mysql更换MyISAM存储引擎为Innodb的操作记录

一般情况下,mysql会默认提供多种存储引擎,可以通过下面的查看: 1)查看mysql是否安装了innodb插件。 通过下面的命令结果可知,已经安装了innod...

2139
来自专栏乐沙弥的世界

基于RMAN的异机数据库克隆(rman duplicate)

      对于基于生产环境下的数据库的版本升级或者测试新的应用程序的性能及其影响,备份恢复等等,我们可以采取从生产环境以克隆的方式将其克隆到本地而不影响生产数...

572
来自专栏乐沙弥的世界

基于 RMAN 的同机数据库克隆

Oracle数据库克隆,也叫着Oracle数据库复制,可以通过基于用户管理的方式来完成,也可以基于RMAN方式来实现。而且Oracle建议使用RMAN方式来实现...

491
来自专栏乐沙弥的世界

ORA-27102: out of memory 故障

      最近的UAT数据库迁移,由于是多个DB需要迁移到同一台机器,一部分完成后,启动后续数据库碰到了ORA-27102错误,提示内存超出,查看系统可用内存...

552
来自专栏杨建荣的学习笔记

一条sql语句“导致”的数据库宕机问题及分析 (38天)

最近测试环境需要做一些变更,把测试环境切分成两套环境,存储空间也需要压缩压缩和整理。 unix组的人已经开始做空间划分了,然后我们需要在此基础上重建一套环境。 ...

3264
来自专栏数据库新发现

Oracle9i新特点:SPFILE的使用--How to set events with spfile and etc

本文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.

311
来自专栏数据和云

深入剖析:update pk会发生什么?

张大朋(Lunar)Oracle 资深技术专家 Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验,曾经服务于ORACLE ACS部门,现就职于...

2798
来自专栏乐沙弥的世界

ORA-19815,ORA-19809 :limit exceeded for recovery files

    数据库重新启动的时候,收到了ORA-19815的错误。从错误的提示来看,是由于闪回区的空间被填满导致无法成功启动。这种情形我们通常考虑的是清除归档日志,...

523

扫描关注云+社区