您好,欢迎光临! 请 |

umount误操作引发数据库宕机

作者: | 分类:Experience, Oracle | Tag:, | 评论:8 
字号:T|T

在开发数据库上,执行完其它测试工作后,随手执行命令卸载光盘,图省事,执行了下述命令:

[root@OEL511gR2 ~]# umount -all

然后,然后,就导致了一则不大不小的数据库宕机!!!
因为,我的开发库文件系统信息如下:

[root@OEL511gR2 ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda1     ext3    9.7G  7.9G  1.3G  87% /
tmpfs        tmpfs    502M     0  502M   0% /dev/shm
/dev/sdb1     ext4     67G   57G  6.5G  90% /u02/rimis_data
172.16.1.100:/backup
               nfs    466G  105G  361G  23% /backup
[root@OEL511gR2 ~]#

而数据库的数据文件信息如下:

[oracle@OEL511gR2 ~]$ rlwrap sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Thu Nov 24 17:09:59 2011
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u01/app/oradata/RIMISDB/system01.dbf
/u01/app/oradata/RIMISDB/undotbs01.dbf
/u01/app/oradata/RIMISDB/sysaux01.dbf
/u01/app/oradata/RIMISDB/users01.dbf
/u02/rimis_data/css_ott.dbf
/u02/rimis_data/css_ltt_bk.dbf
/u02/rimis_data/css_lti_bl.dbf
/u02/rimis_data/css_oti.dbf
/u02/rimis_data/css_ltt_rp.dbf
/u02/rimis_data/css_cdi.dbf
/u02/rimis_data/css_lti_ob.dbf
NAME
--------------------------------------------------------------------------------
/u02/rimis_data/css_ltt_eh.dbf
/u02/rimis_data/css_blt.dbf
/u02/rimis_data/css_ltt_bl.dbf
/u02/rimis_data/css_eci.dbf
/u02/rimis_data/css_ect.dbf
/u02/rimis_data/css_lti_ec.dbf
/u02/rimis_data/css_lti.dbf
/u02/rimis_data/css_ltt_gw.dbf
/u02/rimis_data/css_ltt.dbf
/u02/rimis_data/css_ltt_tr.dbf
/u02/rimis_data/css_lti_rp.dbf
NAME
--------------------------------------------------------------------------------
/u02/rimis_data/css_lti_bk.dbf
/u02/rimis_data/css_gwi.dbf
/u02/rimis_data/css_bli.dbf
/u02/rimis_data/css_lti_tr.dbf
/u02/rimis_data/css_ltt_ec.dbf
/u02/rimis_data/css_gwt.dbf
/u02/rimis_data/css_lti_gw.dbf
/u02/rimis_data/css_cdt.dbf
/u02/rimis_data/css_ltt_ob.dbf
/u02/rimis_data/css_lti_eh.dbf
32 rows selected.
SQL>

接着,邮箱就瞬间收到了来自开发项目组发出的数据库不可用的邮件!
最后,重新挂载磁盘,重启数据库。
一个小插曲,启完数据库后,忘记了启监听,就电话通知开发部门数据库可用。
又接着还是一通反应数据库不可用,罪过啊,手工启监听,手工注册服务!
写在这里,给自己提个醒,在服务器上操作时,记得千万千万要谨慎!!!好在,本次故障中,硬盘没损坏!不然就KO了!

顶一下
(0)
100%
踩一下
(0)
100%

8 篇回应 (访客:5 篇, 博主:3 篇)

  1. gtlions 2011-24-11

    求解:是因为导致/dev/sdb1 卸载了导致的吧?

    #-49楼
  2. Asher 2011-25-11

    reply gtlions:是的,本则故障确实因为/dev/sdb1被卸载导致数据库读写文件故障,最后由PMON后台进程终止了实例。所以,我们在服务器上的操作要注意!

    #-48楼
  3. gtlions 2011-25-11

    还是有点疑问,sdb不是普通的硬盘分区吗?怎么unmount会卸载掉呢?

    #-47楼
  4. admin 2011-25-11

    Reply gtlions:
    /dev/sdb是服务器上的第二块物理硬盘,Linux的文件系统装在第1块儿物理硬盘的第一个主分区也就是sda1上。
    本案例中数据库的部分数据文件是放在/dev/sdb1上存放的,而该硬盘挂载/u02/rimis_data下,umount -all的时候,会将/u02/rimis_data卸载了,这时硬盘还在服务器上,只是从文件系统上已经看不到/u02/rimis_data下的数据了,自然oracle就没法访问/u02/rimis_data下的数据文件了,最终导致数据库故障。
    这样解释可以消除您的疑问么?多谢您的关注!

    #-46楼
  5. gtlions 2011-25-11

    嗯,那就是说:非操作系统所在的硬盘,在系统安装完成后才进行格式化创建分区并挂栽的,这样在卸载的时候会卸载掉非系统所在的分区。
    进一步的是否可以这样理解:除了系统所在硬盘的分区,其他的分区都将会卸载掉。(不管是在安装系统时候创建的分区还是之后创建的分区)?

    #-45楼
  6. gtlions 2011-25-11

    对了,你这个可以用openid登陆吗?

    #-44楼
  7. admin 2011-25-11

    To gtlions:
    我觉得您那样理解不够准确。在本次误操作中使用了umount -all选项时,会卸载除了系统分区之外的其他文件系统。光盘、/backup的NFS文件系统,/u02/rimis_data的EXT4文件系统。
    我觉得您推出的结论:除了系统所在硬盘的分区,其他的分区都将会卸载掉。有待验证。如果您有环境的话,您可以在装系统的时候做多个分区,然后umount -all尝试下。
    不好意思,目前blog还没做openid登录的接口。不过,您可以在blog右下角注册用户,同时欢迎您订阅右上角的RSS阅读。

    #-43楼
  8. gtlions 2011-25-11

    基本上理解了,但是还需要动手验证下,非常感谢你的耐心解答,已经订阅了。

    #-42楼

插入图片

NOTICE1:请申请gravatar头像,没有头像的评论可能不会被回复|头像相关帮助!