记一次数据库宕机处理

早上巡检realsync时发现数据库宕掉了,查看alert发现如下报错:

Thu Dec 18 22:26:18 2014

KCF: read, write or open error, block=0x72d online=1

        file=1 ‘/oradata/****/temp01.dbf‘

        error=27063 txt: ‘IBM AIX RISC System/6000 Error: 28: No space left on device

Additional information: -1

Additional information: 131072‘

Errors in file /u01/app/diag/rdbms/**/***/trace/sjjz_dbw1_418098.trc:

Errors in file /u01/app/diag/rdbms/**/**/trace/sjjz_dbw1_418098.trc:

ORA-63999: data file suffered media failure

ORA-01114: IO error writing block to file 1025 (block # 1837)

ORA-01110: data file 1025: ‘/oradata/**/temp01.dbf‘

ORA-27063: number of bytes read/written is incorrect

IBM AIX RISC System/6000 Error: 28: No space left on device

Additional information: -1

Additional information: 131072

DBW1 (ospid: 418098): terminating the instance due to error 63999

从报错No space left on device,怀疑系空间不足导致的,df查看果然/oradata文件系统剩余空间为0,占用率为100%;

进一步查看temp01.dbf数据库文件属性:

1 /oradata/sjjz/temp01.dbf 1 TEMP 30408704 3712 ONLINE 1 YES 34359721984 4194302 80 29360128 3584

autoextensible为yes,即可以自动对数据文件进行扩展,最大空间为34359721984,31GB。

当io写入时发现已经没有空间写入了,instance abort!

在bing中查询这个ora-63999,果然发现oracle 11g存在这个问题,是由一个隐藏的启动参数决定的,

隐藏参数‘_datafile_write_errors_crash_instance’是在Oracle 11.2.0.1开始导入的,

主要的机能是在,数据文件(sysytem以外表空间)I/O读写错误被发现时,对实例的down进行管理。

Oracle 11.2.0.1 的初始值是

_datafile_write_errors_crash_instance = FALSE

数据文件(sysytem以外表空间)I/O读写错误被发现时,在归档模式下,发生错误的数据文件

被OFFLINE,实例不会down。

Oracle 11.2.0.2开始初始值变成TRUE

_datafile_write_errors_crash_instance = TRUE

因为I/O错误,数据文件读写失败被发现时,ORA-63999错误出力,实例down。

后又查看一篇文章:http://blog.itpub.net/23718752/viewspace-1122411

这个作者说这是oracle11g一个bug,从11.2.0.2就解决了,但是我这个系统是oracle 11.2.0.4,按照文章作者的说明从11.2.0.2在归档模式下不会出现instance abort,我这个数据库是非归档模式的,这个就需要验证下了,有时间在验证下,到时把结果在补充上来。

时间: 2024-10-23 01:05:14

记一次数据库宕机处理的相关文章

独立解决数据库宕机问题

1. 发现数据库宕机,(ps -ef | grep smon )首先考虑是不是RAC,是否影响正常的生成环境.确定大概修复时间.    如果是RAC,那么到到另一台数据库上输入操作命令.查找静态参数文件进行启动. 2.在本地宕机的数据库系统中也可以找到静态参数文件.一般情况下的位置是cd $ORACLE_HOME/dbs  找到静态参数文件,(可以参考另一个实例上的实例 ps -ef | grep smon ) 或者cd $ORACLE_HOME/dbs 3.本次数据库宕机原因,可以去alert

625某电商网站数据库宕机故障解决实录(上)

博客编辑器越来越用不好了,伙伴们将就看,需要排版更好的文档请加Q群246054962. 625某电商网站数据库特大故障解决实录(上) 这是一次,惊心动魄的企业级电商网站数据库在线故障解决实录,故障解决的过程遇到了很多问题,思想的碰撞,解决方案的决策,及实际操作的问题困扰,老男孩尽量原汁原味的描述恢复的全部过程及思想思维过程!老男孩教育版权所有,本内容禁止商业用途. 目录: 625某电商网站数据库特大故障解决实录... 1 1接到电商客户报警... 1 1.1与客户初步沟通... 1 1.2深入沟

625某电商网站数据库宕机故障解决实录(下)

1.4开始进行故障恢复***** 1.重新初始化建库 [[email protected] data]# mkdir mysql [[email protected] data]# chown -R mysql.mysql mysql [[email protected] data]# /install/mysql/scripts/mysql_install_db--basedir=/install/mysql/ --datadir=/data/mysql/ --user=mysql Insta

记一次服务器宕机处理过程

今天整理之前的运维资料,发现了自己整理的一次刀片服务器(运行的vmware虚拟化)事故处理流程,所有记录下,备忘. 一.事件处理过程 14:10 接到机房运维工程师通知,Opmanager监控系统上出现了多台服务器宕机现象,并且均为虚拟机. 14:12 通知机房运维工程师检查HP刀片服务器是否有告警,远程登录vcenter进行检查.远程查看发现ESX04(10.203.11.64)出现告警,告警信息如下图所示:  14:15 通知工程师ESX04出现告警,然后确认该刀片服务器是否存活,并进入机房

(转)625某电商网站数据库宕机故障解决实录(下)

1.4开始进行故障恢复***** 1.重新初始化建库 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [[email protected] data]# mkdir mysql [[email protected] data]# chown -R mysql.mysql mysql [ro[email protected] data]# /install/mysql/sc

(转)625某电商网站数据库宕机故障解决实录(上)

625某电商网站数据库特大故障解决实录(上) 原文:http://oldboy.blog.51cto.com/2561410/1431161 这是一次,惊心动魄的企业级电商网站数据库在线故障解决实录,故障解决的过程遇到了很多问题,思想的碰撞,解决方案的决策,及实际操作的问题困扰,老男孩尽量原汁原味的描述恢复的全部过程及思想思维过程!老男孩教育版权所有,本内容禁止商业用途. 目录: 625某电商网站数据库特大故障解决实录... 1 1接到电商客户报警... 1 1.1与客户初步沟通... 1 1.

更换磁阵硬盘,数据库宕机

昨天ibm磁盘阵列更换一块损坏的硬盘(11号硬盘),厂家换上去的硬盘数据同步失败(12磁盘 ==>11磁盘),而且发现磁阵中的热备盘也无显示同步失败,几小时后连接存储的相关oracle数据库RAC1开始大量报错,节点2直接dg 不能mount挂掉了,rac1日志: Reread of rdba: 0x03801dbb (file xx, block xxxx) found same corrupted data--xx和xxxx每次报错不相同 重启rac2无法读取controlfile 文件.重

数据库修改字段导致宕机

170614 23:28:56 [ERROR] Slave SQL: Error 'Got error 64 'Temp file write failure' from InnoDB' on query. Default database: 'loandb'. Query: 'ALTER TABLE 'trd_loanapply DROP COLUMN LAP_SIGNRATE , Internal MariaDB error code: 1296 170614 23:28:56 [Warni

Redis的KEYS命令引起RDS数据库雪崩,RDS发生两次宕机,造成几百万的资金损失

最近的互联网线上事故发生比较频繁,20180919顺丰发生了一起线上删库事件,在这里就不介绍了. 在这里讲述一下最近发生在我公司的事故,以及如何避免,并且如何处理优化. 间接原因还有很多,技术跟不上业务的发展,由每日百万量到千万级是一个大的跨进,公司对于系统优化的处理优先级不高,技术开发人手的短缺 第一次宕机20180913某个点,公司某服务化项目的RDS实例连接飙升,CPU升到100%,拒绝了其他应用的所有请求服务整个过程如下: 监控报警,显示RDS的CPU使用率达到80%以上,DBA介入,准