DBA生存警示：误关闭生产库案例及防范建议

编辑手记：对于资深的老DBA们，他们在漫长的职业生涯中养成了很多稀奇古怪的守则，以在复杂多变的环境中“幸存”，这源于无数血泪的教训，我曾经在《数据安全警示录》一书收录了大量现实案例，现在整理分享给大家，共为警示。

很多DBA还经历过误操作关闭主机或生产数据库的情况，这种误操作绝对是刻骨铭心的，往往一个回车下去，就幡然醒悟，但是很多时候为时已晚。

案例分享



1.误关闭生产数据库

说一个刚做DBA的时候的事儿，大家别笑啊。

一边在本机上做实验的时候一边监控生产库，机器中开了N个黑窗口，累了，本机上改完配置后需要重启库，shutdown immediate，2分钟没有反应，脑袋“嗡”的一下，知道发生什么事情了，马上重新连接一个session，shutdown abort ，然后通知应用人员，数据库发生误操作，需要马上重启应用，OK，数据库起来，应用起来，新数据进来。 前后总共宕机时间13分钟，不过在线数据没有丢失，因为应用端有写CACHE机制。结果还好，没有被追究责任，算作一次维护操作。 经验：以后每次敲完命令，按回车之前，停一秒钟。

2.误操作关闭数据库主机

一次数据库打补丁时，原本是要在Sql*PLUS登陆后shutdown immediate，但那时敲得太快没注意 SQLPLUS session 已经退出了，结果是在OS级别shutdown immediate，把服务器给停了......我的乖乖啊，问题是该服务器在国外啊。

3.误操作影响主机HA

有一次在HP的ServerGuard 的双机环境，备机是用做测试库的。我发现起了一个生产机的instance 在上面。尝试了alter database mount，发现并没有mount。而且正常情况下，ServerGuard的备机应该不会有生产机的instance。断定是起了无效的的instance。只是instance，并没有mount，然后将该instance执行了一个shutdown immediate......没有想到那边的生产机也在进行shutdown。而且，ServerGuard的包有问题，数据库每次起来以后就自动就重起了。折腾了2个多小时。

4.误操作关闭数据库主机

有一次半夜被call到机房，头有些晕沉，想找一台windows telnet上DB去检查检查，因为用了屏幕切换器，一个Ctrl+Alt+Del组合键下去，一台DB服务器被我reboot了(linux下没有屏蔽掉Ctrl+Alt+Del三键重启)，吓出一身冷汗来，幸亏是一个小型DW应用，晚上不会用到。 此后，凡是在Linux下跑的Oracle，装好OS后我一律最先将/etc/inittab里的ca::ctrlaltdel:/sbin/shutdown -t3 -r now这一行给屏蔽掉。

5.误操作关闭生产主机

我最惨的一次是上了十几个小时夜班后正准备下班，点进VM执行 Inti 0，却忘记有从这个VM窗口telnet到生产环境cp参数文件，而且等数据库状态监控状态报警后才反应过来......

还好是RAC，但也造成不小影响，从此下任何命令钱先check 过

另外，个人总结在UNIX下尽量用tab得到文件名和路径名，有助于避免空格错误。

防范建议

1.尽量避免层层跳转的服务器登陆方式

虽然很多企业数据环境通常都要经过层层跳转才能够访问，但是不可避免的，跳转的次数增多也就增加了出错的可能性，所以应当尽量减少跳转次数，禁止在一个主生产节点再跳转到另外的主生产节点。

在操作时，也应当通过hostname等方式确认连接到的服务器主机。

2.完成操作尽快退出生产业务服务器

当在生产服务器上完成工作后，应当尽快退出，以防止其他工作干扰后，因为疏忽而出现误操作。尤其是当离开电脑前时，应当退出或锁定操作界面，防止他人误操作。

3.经常性确认服务器、数据库和路径标示

应当经常性确认主机名称、当前路径、数据库名称等信息，防止无意识的误操作。

尤其是当重新或临时接触到操作终端时，如果不能明确看到服务器或数据库标示，则应当首先查看这些信息。