ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 磁盘空间瞬时占满引发实例崩溃一例

磁盘空间瞬时占满引发实例崩溃一例

原创 Linux操作系统 作者:realkid4 时间:2013-10-19 22:32:30 0 删除 编辑

 

理想情况下,我们的系统按照职责进行划分部署。进行实际投产环境部署的时候,也尽量本着服务器职能单一的原则。这样做是非常有必要的,不同的应用服务器之间同时运行,在资源、性能、配置上可能存在很多的隐忧。在很多时候,一些故障就是由于系统行为之间的差异造成的。

 

本篇记录一个之前遇到的实例。案例不大,可借鉴之处不少。

 

1、问题介绍

 

笔者兼职管理的一套系统,是一个虚拟机上运行的Window 2003服务器。该机器很老了,上面运行项目组测试使用的QCHP Quality Control测试管理系统)和后台数据库。因为是非关键系统,又是项目组级别,所以资源上比较窘迫。后台Oracle数据库版本是10g,笔者设计了一套以RMAN+Exp组合的备份还原方案。

 

事情的开始是这样的,一天上班10点后,就有项目组开发测试人员报告说QC登录失败,报错login error

 

QC斗争的经验告诉笔者首先区别的是应用服务器故障(JBoss)还是数据库服务器故障。如果是数据库端,要从监听器、实例和数据库几个组件进行逐步诊断。

 

经过诊断,发现应用服务器没有故障,监听器运行正常,问题发生在数据库实例。实例崩溃停止运行。

 

诊断数据库实例过程中,alert log是一个不可缺少的环节。故障片段如下:

 

 

Tue Feb 19 00:56:04 2013

Thread 1 advanced to log sequence 3358

  Current log# 3 seq# 3358 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\REDO03.LOG

Tue Feb 19 09:40:24 2013

Thread 1 advanced to log sequence 3359

  Current log# 1 seq# 3359 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\REDO01.LOG

Tue Feb 19 09:58:13 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_lgwr_5940.trc:

ORA-00221: error on write to control file

Tue Feb 19 09:58:14 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_mman_4296.trc:

ORA-00221: error on write to control file

Tue Feb 19 09:58:21 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_dbw0_500.trc:

ORA-00221: error on write to control file

Tue Feb 19 09:58:21 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_reco_2684.trc:

ORA-00221: error on write to control file

Tue Feb 19 09:58:21 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_smon_5356.trc:

ORA-00221: error on write to control file

Tue Feb 19 09:58:23 2013

Instance terminated by CKPT, pid = 4140

 

 

日志信息显示,从接近10点的时候,数据库期望向control file中写入数据。注意:控制文件是Oracle的心脏,正常运行情况下,每个几秒钟数据库都会向Control File写入数据。日志中,lgwrdbwrrecosmon分别尝试写入控制信息。最后SMON写入过程,引起了严重问题,CKPTCheck Point)进程将数据库强制终止。

 

2、问题分析和进展

 

应该说,问题是比较严重的。Control FileOracle的心脏,如果Control File写入故障,是一种严重问题。笔者尝试启动数据库。

 

 

Tue Feb 19 09:58:23 2013

Instance terminated by CKPT, pid = 4140

Tue Feb 19 10:31:47 2013

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 2

Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

(过程略......)

 

SMON: enabling tx recovery

Tue Feb 19 10:32:14 2013

Database Characterset is ZHS16GBK

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

QMNC started with pid=19, OS id=6452

Tue Feb 19 10:32:21 2013

Completed: ALTER DATABASE OPEN

 

 

启动成功了,而且之后运行几个小时也没有明显的问题。操作系统磁盘空间有10G左右,是有富余空间的。

 

控制文件Control File如果有严重的故障问题,必然不能顺利启动。为了保证文件的质量,一般采用多重冗余策略管理Control File

 

 

  control_files            = D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL01.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL02.CTL, D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL03.CTL

 

 

系统控制文件选择三个冗余,应该说一般的坏块和损坏都不会有严重的问题,更不会导致到实例终止的程度。

 

到此笔者也没有什么思路,Trace文件里面也没有什么额外的信息。此时能够想到的可能性有几个:

 

ü  文件系统整个损坏,进程无法写入。因为是虚拟机环境,系统上其他程序运行还算正常,所以大规模的文件系统问题不太可能发生;

ü  控制文件损坏,单一控制文件损坏是可能发生的。但是三个副本文件同时损坏几率比较低。而且在启动过程中,有对于文件一致性的检查。三个文件同时在相同位置上损坏,可能性较低;

ü  空间问题,生产环境下存储空间不足是经常出现的问题。如果存在空间不足的情况,数据库被终止也是可能的。但是笔者登录系统的时候,的确还有约10G空间,之后重启数据库也可以启动;

 

因为没有什么额外的思路,数据库也能够启动。所以只能暂时作罢。

 

3、问题第二次出现

 

第二天,问题再一次出现。依然是数据库被终止。日志如下:

 

 

Wed Feb 20 06:57:05 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_ckpt_7776.trc:

ORA-00206: error in writing (block 3, # blocks 1) of control file

ORA-00202: control file: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL03.CTL'

ORA-27072: File I/O error

OSD-04008: WriteFile() 失败, 无法写入文件

O/S-Error: (OS 112) 磁盘空间不足。

ORA-00206: error in writing (block 3, # blocks 1) of control file

ORA-00202: control file: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL02.CTL'

ORA-27072: File I/O error

OSD-04008: WriteFile() 失败, 无法写入文件

O/S-Error: (OS 112) 磁盘空间不足。

ORA-00206: error in writing (block 3, # blocks 1) of control file

ORA-00202: control file: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\OTSTEST\CONTROL01.CTL'

ORA-27072: File I/O error

OSD-04008: WriteFile() 失败, 无法写入文件

O/S-Error: (OS 112) 磁盘空间不足。

(篇幅原因,省略部分……)

Wed Feb 20 06:57:31 2013

Errors in file d:\oracle\product\10.2.0\admin\otstest\bdump\otstest_smon_18376.trc:

ORA-00221: error on write to control file

 

Wed Feb 20 06:57:33 2013

Instance terminated by CKPT, pid = 7776

 

 

比前一天,告警日志中有额外的信息。数据库是在早上7点前出现的问题。实例崩溃之前有一系列的空间使用问题,Oracle报告空间用尽,无法写入到control file中。

 

但是当前空间还有接近10G空闲,而且数据库还能够正常启动。手工拷贝文件到目标盘上也没有问题。

 

唯一可能的就是在当时,操作系统中有作业运行,将空间使用尽,之后释放。用尽的那个时刻,Oracle Control File写入动作被禁止,进而导致Instance终止。

 

那么,究竟是什么作业呢?

 

经过和系统管理沟通,原来该机器上还有SVN服务器,而且前一段有多个项目将源代码转移到这台机器上。这种基于文件系统的配置管理工具,对空间的使用是很高的。

 

那么,为什么会在上班前用尽空间呢?根据SVN管理手法,每天早上几个项目都进行代码集成备份。备份格式虽然是压缩格式,使用空间不多,但是这个过程伴随着将数据拷贝出来进行逐步压缩的过程。多个项目同时进行这个动作,会在磁盘空间上有一个瓶颈期,如果磁盘原有空间不多,理论上是可能发生瞬间用尽磁盘空间的情况的。

 

由于没有进行当时的实时监控,所以只能是暂时的猜想。和项目组讨论之后,建议两个策略:第一是清理空间,删除没用的数据文件,给系统留出更多的磁盘空间。第二个是长期策略,申请专用的配置管理服务器,将SVN转移到新机器,专机专用。

 

短期有效策略是第一个,当天整理出10G空间,SVN管理员又进行了备份策略时间段的调整。之后,Oracle Instance终止问题没有再次出现,问题解决。

 

4、结论

 

这个案例告诉我们几个教训:

 

ü  故障往往是一个综合性的症状和原因。很多我们遇到的故障,可能根本原因不在Oracle本身,可能是Oracle与其他系统交互相互影响的结果。这个时候,需要我们广博的见识和知识基础,多看多学多积累。数据库不是专才,而是通才;

ü  进行服务器部署的时候,专用是非常重要的。对一些重要的系统,如果没有经济预算压力,专机专用尽量做到。而且,随着虚拟化技术的普及,一台服务器也是比较容易的;

ü  沟通解决问题。对于综合性的问题故障,我们的专业永远是不够的,需要团队合作和沟通。DBA只有和系统管理员、操作系统和网络管理员密切合作协作,才能解决大问题;

ü  层层递进、抽丝剥茧。在看似不可能的问题面前,不要轻易下结论。多实验观察,才能有所成长;

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-774675/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7672529