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了！

Asher| 2011年11月25日

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

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

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

对了，你这个可以用openid登陆吗？

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

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