（看这里→ →这是数据库安全专题的最后一期?我们会从这九期参加活动的童鞋们中抽取两位送出奖品哦~中奖结果下周见?）
除了数据库层面，在主机、操作系统、存储层面也有很多典型案例，如果不够谨慎，主机网络层面的误操作也可能对系统产生致命的影响。
案例分析
1.误发出系统命令
HP UNIX Oracle10.2，我用root登陆后，建立了一个新主机用户，不知不觉敲了个hostname –a，大家知道后边发生什么了吗？
是和uname -a搞混了，hostname -a直接把主机名改成-a了......
listener是监听主机名的，现在找不到主机了，连续报错，还有后台trc文件也连续报错，这个主机上共有4个实例，同时连接不上......壮观啊......很快日志占满文件系统。
查不出原因，但是发现文件系统使用得很快，就想先停库，再查原因了。结果，启动的时候都ora600了。好在是测试环境的数据库，不是正式的。真是刻骨铭心啊。
2.误切换生产存储
一次冰凉透顶的操作，去年某天下午，本来是对灾备端的盘柜做HA切换，头脑一昏，随手一按，把生产端的盘柜进行了手动HA切换，20多套数据库系统在上面跑......后果不堪设想，还好一个急智，赶快又切换回来，装作什么事没有，手一直颤抖.....过后偷偷问一些在线服务系统有没有什么异常，MM只是说有几分钟很慢，数据库没反应，过后又正常了，汗....
从此对生产环境有一种“非诚勿扰”的感觉，敬而远之。
3.存储维护危险误操作
在cx700的存储navisphere管理界面，配置一个存储。同事接过去打开了生产环境另外一个存储的IE窗口，我又接手过来，一恍惚看这个存储的配置与我打开的一样，就开始做删除storage group的操作。还好我旁边另外一个同事看主机名不对，制止了我继续删除（我当时对他讲解了一下配置存储的步骤然后开始操作）。
删除了lun就丢生产环境的CRM数据了。
这个事情很可怕，那天人状态不怎么好。以后做事情越是知道状态不好，越要加倍谨慎。还有以前删除文件用相对路径来删除，../path 方式，误删除了测试环境的oracle程序，以后都用绝对路径了。
4.误删除操作系统文件
一次在IBM p570上安装RAC，由于客户网络有问题，结果失败，在删除RAC时rm -inittab*.crsd等几个RAC的启动文件，一不留神把AIX的一个文件删了，结果系统起不来了。后来多亏IBM的工程师恢复了系统。结果晚上3点才收工。
5.误操作执行系统命令
生产环境增加节点，熬了两天两夜，同事在生产机上执行了pvid=yes 导致数据丢失，最后奋战两天重新安装RAC。
参考建议
1.超级用户和数据库用户严格分离
在生产环境中，不应该给DBA以root权限，以防止不到操作给整个系统带来的影响，即便DBA可能也很了解系统，但是专业分工要求有系统管理员去执行系统层面的维护工作。
避免因为DBA的操作不当导致的系统故障。
2.事关存储无小事
存储最终容纳着用户的所有数据，所以针对存储的任何操作都不能草率，当增减硬盘，格式化分区时，都要严格进行磁盘确认、分区比较，避免因为误操作而“釜底抽薪”。
3.电源即Power
电源也就是Power，是所有动力的来源，所以当中断电源时，系统的所有环境都可能遭受影响。在处理面对电源问题时，应当慎之又慎，因为断电而导致数据库无法启动的案例比比皆是。不要让数据库因为电源问题而崩溃。
以上内容摘录自盖国强《OracleDBA手记4数据安全警示录》。
如果你也曾遇到类似的案例，欢迎点击左下角【阅读原文】告诉小墨墨，全部9期结束后，我们会从参与活动的朋友中抽出两位，各送出盖国强签名版《数据安全警示录》一本，大陆地区包邮。
（封面配图来自：51CTO.com）
关注我们
【iPhone用户】点击标题下方“云和恩墨”或点击右上角关注“查看公众账号”可直接关注，或搜索“enmotech”
【安卓用户】点击标题下方“云和恩墨”直接关注，或搜索“enmotech”
