请列出你在从事DBA生涯中,最难以忘怀的一次误操作(1)

请列出你在从事DBA生涯中,最难以忘怀的一次误操作(1)
2011年06月23日
　　注：itpub上一个帖子，觉得非常好，遂简单整理。
　　原URL：http://ms.itpub.net/viewthread.php?tid=911086&extra=&page=1
　　请列出你在从事DBA生涯中,最难以忘怀的一次误操作
　　大家相互学习和彼此警惕
　　1、一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill,数据库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了.好的是库起来了,这个故障,我一直牢记于心.
　　现在做任何操作是,都要检查正确后再敲回车.
　　2、在linux平台上，一次不小心操作，把oradata下所有的东西全删除了。至今铭刻于心
　　3、误操作多了，误删数据，误连接数据库，误拔电源，当然不全是自己操作的，也有看别人操作的，哪个DBA没犯过错？关键是要通过机制来尽量避免犯错，尤其是重复错误
　　4、一次误删了个表,最后恢复了,丢了一天数据.加了一晚上班,至今记得.
　　人越累的时候就越容易犯错误,我就是在最后快下班的几分钟犯的错误.
　　5、tar -cvf *.log
　　直接把前面几个online redo log tar进了最后一个online redo里面。。。幸好不是current的
　　6、在一次测试过程中，把一个在本机执行的删除所有非系统用户的脚本，错误的粘到一个开发数据库的sqlplus窗口中。
　　幸好在30秒内就意识到了错误，及时中止了脚本的运行，只删除了一个无关紧要的用户
　　7、我最惨，有一次把一个表一不小心给truncate了，上千万条记录一眨眼就没了；提心吊胆的陪了3天也没有把这个表搞定；最后不了了之了。
　　8、半夜加班，系统上线和数据迁移一起，在开始前进行了冷备文件，当上线和数据迁移要完的时候，当时不知道怎么想的可能是半夜脑壳发昏，就在解压TAR把当前数据文件覆盖了，辛好当时意识到了中止了解压，并且被覆盖的数据文件还没有数据。当时赶快把数据文件离线，删除，重建，不然要被旁边的同事海揍
　　最近复制粘贴很容易搞错窗口。辛好还没出大问题，不过已经深深警惕了
　　9、used to have a script written by someone else to run in default directoy, it will delete all the dump file, logs, etc, one day by mistake run it under $ORACLE_HOME... end up the binary was gone luckily it was after work and dev environment, Call NOC to restore everything asap ( within 1hr)...
　　lesson: never run script if you donot read it carefully and know exactly what it is
　　10、开了两个PLSQL DEVELOPE窗口，一个生产的，一个非生产的，同名用户，同表空间名，结果非生产的建用户脚本在生产中跑了一下，非生产是grant limit tablespace to XXX的，结果在生产中跑了以后，生产中的用户变成LIMIT了，结果程序出错，表空间不足。导致应用出错半个小时后才处理好。
　　这个太惨痛了，建议所有的使用多个环境的人，并且操作多个PLSQL DEVELOPE的人尽量只开一个窗口操作，或者是操作生产的时候，用只读的查询用户。
　　11、2004年一次下午17点左右在schema  A 下一个表上增加一个字段(对于在schema  A范围来说这个字段增加当时是不会有问题的)，一加上去，系统load立即狂飙……结果在schema B 下有一个包，里面有引用schema  A 的这个表，没check倚赖关系以为A 和 B 之间没有联系，结果这个包编译不过去被大量进程尝试编译，最后只有杀掉该相关应用所有进程重新连接才恢复。这次故障导致我们一个无故障最长时间的团队免费去海南旅游三天的机会丧失。当时的教训就是任何ddl的变化都需要check这个对象可能被引用的对象，现在已经延伸到任何频繁被访问的sql了，基本频繁访问的应用要做ddl都要深夜才能做了。
　　12、我最惨的一次是忘记把开发设置在参数文件中的nologging参数取消了。
　　结果数据库上线后发生了一次网络风暴，所有机器全搞死了，重启後没一台数据库能起来。
　　13、那