DBA职业生涯之误删除篇

前面我提到严谨这一素质对于DBA的重要性，在ITPUB论坛上曾经有过一个热烈的主题：“请列出你在从事DBA生涯中，最难以忘怀的一次误操作”。

这一主题引起了大家普遍的兴趣，很多有趣的案例呈现出来，我摘录了一些和误删除有关的操作，看看都有哪些一时马虎、不够严谨会犯下的过失，大家应引以为戒，共同警醒：

1. 在Linux平台上，一次不小心操作，把oradata下所有的东西全删除了。

这样的误操作，教训是极其惨痛的，所以备份对于DBA来说仍然是最重要的。

2. 一次误删了个表，最后恢复了，丢了一天的数据。加了一晚上班，至今记得。

人越累的时候就越容易犯错误，我就是在最后快下班的几分钟犯的错误。

一定要记住墨菲定律，越着急就越容易犯错误，DBA千万不要赶着去做一件事。

3. 在一次测试过程中，把一个在本机执行的删除所有非系统用户的脚本，错误地粘到一个开发数据库的sqlplus窗口中了。

如果你不注意剪贴板，它就会害你！

4. 有一次一不小心把一个表给truncate了，上千万条记录一眨眼就没了。

ddl操作一定要谨慎啊！

5. rm -rf /opt/ora92/* 在测试库中本来想删除数据库，结果错误地把Oracle软件删除了。

rm -rf是相当恐怖的，每个DBA都应该学会不要直接使用这个命令。

6. 不小心用rm -rf /home目录下的所有文件，/home目录下放的有账务系统的app。一看到删除的路径的不对时，挽救已经来不及了。

又是一个rm -rf的狠操作。

7. 删除一些trace文件，然后就直接删除rm orcl*，结果通过vpn到生产的网络太慢，命令刚慢慢地显示出来，看都没看直接按回车，结果执行的命令却是rm orcl *，因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。

网络慢的确害惨过很多人，所以网络可能存在问题时，任何操作都要慎重，不行可以使用脚本在后台跑。

8. 有很多在OEM/Toad中误击键盘删除用户或表空间的情况。

实际上，我们看到，很多误操作都和技术能力基本无关，只是要细致、严谨，再认真一点。DBA有些素质和习惯是必须养成的。

很多时候，只要多思考一些，就可以将工作做得更加完美，就可以严谨地避免很多问题，举一个DBA可能经常面对的工作任务作为例子：

如果在数据库中执行ddl操作，比如：

        CREATE INDEX / REBUILD INDEX …ONLINE COMPUTE
        STATISTICS / GRANT / REVOKE / COMPILE / ANALYZE
        / DBMS_STATS….

进行严密严谨的思考，这些操作可能带来什么后果？

通常我们都知道，ddl会使解析过的SQL失效、会使存储过程等对象失效发生重编译、也有可能引起SQL执行计划的改变……

这些可能在一个繁忙的业务数据库中带来灾难，如果大量的SQL同时失效，同时重新解析，就可能带来大量的Shared Pool与Library Cache的竞争，SQL解析与竞争又会导致CPU的高消耗，这些在繁忙系统中可能会导致负荷突然升高，严重的甚至会导致系统阶段性地挂起。

已经有很多DBA在这些问题上付出了惨痛代价，而我只提醒大家，做事时要能够明确工作的性质、分析潜在的风险、回避可能引发的问题。