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

 

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

 

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

 

1、问题介绍

 

笔者兼职管理的一套系统，是一个虚拟机上运行的Window 2003服务器。该机器很老了，上面运行项目组测试使用的QC（HP 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写入数据。日志中，lgwr、dbwr、reco和smon分别尝试写入控制信息。最后SMON写入过程，引起了严重问题，CKPT（Check Point）进程将数据库强制终止。

 

2、问题分析和进展

 

应该说，问题是比较严重的。Control File是Oracle的心脏，如果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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-774675/