umount误操作引发数据库宕机
在开发数据库上，执行完其它测试工作后，随手执行命令卸载光盘，图省事，执行了下述命令：
[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了！
From OracleOnLinux, post umount误操作引发数据库宕机
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
Reply gtlions:
/dev/sdb是服务器上的第二块物理硬盘，Linux的文件系统装在第1块儿物理硬盘的第一个主分区也就是sda1上。
本案例中数据库的部分数据文件是放在/dev/sdb1上存放的，而该硬盘挂载/u02/rimis_data下，umount -all的时候，会将/u02/rimis_data卸载了，这时硬盘还在服务器上，只是从文件系统上已经看不到/u02/rimis_data下的数据了，自然oracle就没法访问/u02/rimis_data下的数据文件了，最终导致数据库故障。
这样解释可以消除您的疑问么？多谢您的关注！
嗯，那就是说：非操作系统所在的硬盘，在系统安装完成后才进行格式化创建分区并挂栽的，这样在卸载的时候会卸载掉非系统所在的分区。
进一步的是否可以这样理解：除了系统所在硬盘的分区，其他的分区都将会卸载掉。（不管是在安装系统时候创建的分区还是之后创建的分区）？
To gtlions:
我觉得您那样理解不够准确。在本次误操作中使用了umount -all选项时，会卸载除了系统分区之外的其他文件系统。光盘、/backup的NFS文件系统，/u02/rimis_data的EXT4文件系统。
我觉得您推出的结论：除了系统所在硬盘的分区，其他的分区都将会卸载掉。有待验证。如果您有环境的话，您可以在装系统的时候做多个分区，然后umount -all尝试下。
不好意思，目前blog还没做openid登录的接口。不过，您可以在blog右下角注册用户，同时欢迎您订阅右上角的RSS阅读。
求解：是因为导致/dev/sdb1 卸载了导致的吧？