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

时间： 2024-09-20 22:28:57

数据库突然宕机无法open的问题及解决的相关文章

数据库突然宕机的问题及分析

昨天晚上,某个环境的数据库在做一个压力测试的时候突然宕机了.这个问题比较急.马上查看日志文件. 看到了如下的一段,报了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.2aa5

SureHA集群服务器处于保留（宕机后重新启动）状态的解决方法

SureHA集群服务器处于保留(宕机后重新启动)状态,如下图: 原因分析: 在SureHA软件中将自动复归设置为"关闭",如下图,服务器重启后会进入保留(宕机后重新启动)状态. 注意:通过管理页面直接重启集群,服务器不会进入保留状态. 解决方案: 在SureHA的管理页面中,选中进入保留状态的服务器,右键单击选择"恢复"即可,如下图: 如需改变设置,切换到设定模式,右键选择集群,在自动复归选项卡,设置为开后应用配置文件即可.

网站seo：虚拟主机宕机检测与解决之道

大家好!我是<搜索宝自动音乐盒>网站的CEO fee.很高兴在这里认识大家,我很希望和大家坦诚的交个朋友,分享一下我们当站长的心得. 网站的稳定性,与速度,是对搜索引擎是否友好的重要标准之一,也是搜索引擎排名的重要参数.试想一个网站,如果三天两头不能访问,那么搜索引擎蜘蛛会经常来吗?轻者,蜘蛛更新快照,异常缓慢.重者,从搜索引擎上除名.蜘蛛如果爬行失败,你的网站将返回404错误,然后百度就知道,你的网站无法访问了.等到下一次,如果爬到相关你网站的链接,还是无法访问.那百度对你网站的存在性,就十

SEO诊断之服务器宕机导致网站被K

大家好,我是虚子雨.对于SEO诊断,一直是我坚持的一项工作,因为SEO诊断,诊断的是网站的过去和现在的病态,然后通过诊断找到网站的优化调整方向,这才是SEO诊断的魅力所在,就像一位神医,找到病人的病因,并开出合理的药方,迅速的治好他的病.最近一段时间,SEO届可以哀鸿一片,因为百度进行了有史以来最大规模的一次K站,相当大的一部分站长手上的网站都被降权或者被K,当然这对于想迅速学习SEO优化诊断知识的朋友,这些典型的网站就是一个比较不错的机会. 昨天在群里喊了几句,让群友给几个典型的案例,我这边来

Twitter网站因用户发布消息过多而宕机

北京时间1月20日晚间消息,据国外媒体报道,从美国东部时间1月20日6:40(北京时间1月20日19:40)开始,Twitter网站无法访问.Twitter主页显示,用户发布的消息过多,已超出Twitter的处理能力. Twitter的应用程序接口(API)同样出现问题,导致数千第三方应用和服务无法正常工作.本月到目前为止,Twitter的网站运行情况良好,正常工作时间达到99.89%. 美国东部时间1月20日7:25(北京时间1月20日20:25),Twitter在网站状态博客中表示,由于消息

典型案例之网站因为服务器宕机导致网站被K

摘要: 对于SEO诊断,一直是我坚持的一项工作,因为SEO诊断,诊断的是网站的过去和现在的病态,然后通过诊断找到网站的优化调整方向,这才是SEO诊断的魅力所在,就像一位神医,找到病人 对于SEO诊断,一直是我坚持的一项工作,因为SEO诊断,诊断的是网站的过去和现在的病态,然后通过诊断找到网站的优化调整方向,这才是SEO诊断的魅力所在,就像一位神医,找到病人的病因,并开出合理的药方,迅速的治好他的病.最近一段时间,SEO届可以哀鸿一片,因为百度进行了有史以来最大规模的一次K站,相当大的一部分站长手

MySQL集群节点宕机，数据库脑裂！如何排障？

作者介绍 王晶,中国移动DBA,负责"移动云"业务系统的数据库集成架构设计.运维.优化等工作:擅长技术领域MySQL,获Oracle颁发的"MySQL DBA"官方认证,熟悉MySQL复制结构.MHA.cluster等多种架构及运维优化.   发现故障的时间正值大年初二,在各种铺天盖地的拜年信息和微信红包之中,我发现了手机上的这条告警通知:   PROBLEM:Disaster: Galera cluster has node down.我生产环境的Galera集群

美联社新闻数据库宕机5小时 波及美大部分报纸

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 北京时间10月115.html">26日上午消息,据国外媒体报道,周一美联社遭遇计算机故障,在5小时中各家报社及其他一些新闻媒体无法收到该社的大量报道. 故障发生于美国东部时间周一下午3时(北京时间周二凌晨3时),当时美联社正试图安装微软推荐的一个安全补丁.该社希望在下周的美国全国和各州大选前提高安全性. 美联社首席信息官洛林

一次数据库宕机问题的分析

今天来到办公室,发现有一台服务器中的数据库实例停掉了.这种情况真是意料之外,尤其是我还不是很熟悉这台机器的服务. 赶紧查看数据库日志,可以看到数据库在昨晚停掉了,从日志来看没有人为的痕迹. 在宕机之前,有下面的日志.在此截取一部分.TNS-12560: TNS:protocol adapter error opiodr aborting process unknown ospid (33498) as a result of ORA-609     ns secondary err code: