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

最新推荐文章于 2021-04-13 23:51:26 发布

cuiding8243

最新推荐文章于 2021-04-13 23:51:26 发布

阅读量94

点赞数

最近看了些帖子——请列出你在从事DBA生涯中,最难以忘怀的一次误操作 大多数灾难都是人为的，引以为戒

“一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill,
则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了.
好的是库起来了,这个故障,我一直牢记于心.
现在做任何操作是,都要检查正确后再敲回车.”
“在linux平台上，一次不小心操作，把oradata下所有的东西全删除了。”【删东西前一定要确认当前的目录】
“误操作多了，误删数据，误连接数据库，误拔电源，当然不全是自己操作的，也有看别人操作的，哪个DBA没犯过错？关键是要通过机制来尽量避免犯错，尤其是重复错误”
“一次误删了个表,最后恢复了,丢了一天数据.加了一晚上班,至今记得.
人越累的时候就越容易犯错误,我就是在最后快下班的几分钟犯的错误.”
“在一次测试过程中，把一个在本机执行的删除所有非系统用户的脚本，错误的粘到一个开发数据库的sqlplus窗口中。
幸好在30秒内就意识到了错误，及时中止了脚本的运行，只删除了一个无关紧要的用户”【有时候为了方便和偷懒，经常使用CTRL+C,CTRL+V，殊不知很多时候粘贴板里的东西可能不是你想想中的；还有的时候，明明是要复制，不小心按了粘贴，鬼知道你的粘贴板里是什么？看RP吧；此外复制粘贴很容易搞错窗口】
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
2004年一次下午17点左右在schema A 下一个表上增加一个字段(对于在schema A范围来说这个字段增加当时是不会有问题的)，一加上去，系统load立即狂飙……结果在schema B 下有一个包，里面有引用schema A 的这个表，没check倚赖关系以为A 和 B 之间没有联系，结果这个包编译不过去被大量进程尝试编译，最后只有杀掉该相关应用所有进程重新连接才恢复。这次故障导致我们一个无故障最长时间的团队免费去海南旅游三天的机会丧失。当时的教训就是任何ddl的变化都需要check这个对象可能被引用的对象，现在已经延伸到任何频繁被访问的sql了，基本频繁访问的应用要做ddl都要深夜才能做了。【
DBA_DEPENDENCIES】
删除一些trace文件，然后就直接删除rm orcl*，结果通过vpn到生产的，网络太慢，命令刚刚慢慢的显示出来，看都没看直接按回车，结果执行的命令却是rm orcl *，因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。出了一身冷汗，试想，如过是删除数据文件目录下的内容，那立马死敲敲了

到现在为止，每次都要等命令完全显示出来，从头到尾看一遍再执行。
不过，大多数错误都是在很繁忙或者很疲劳的情况下发生的，呵呵，看来dba应该多休息才是。
我在一个表空间上添加一个数据文件,对于DBA来说是再平常再简单的不过一件事了, 可是由于添加一个数据文件,差点当机

由于系统用得是raw device,我在添加一个数据文件时,事先没有检查这个LV是否存在,简单地看了当前的数据库中的数据文件所用的LV序号,就以简单序号+1 的方式添加了,结果也算是不走运,正好没有这个LV,ORACLE或者说UNIX操作系统当作了一个一般的文件来创建了.由于是创建在/dev/vgxx中,所以这时搞得UNIX的根目录没有了空间,这个数据文件刚创建完成,其他用户就无法登录了,无法创建新的连接了.因为根目录没有空间了 .更不幸的是已经断开了这个操作系统连接.新的连接又无法创建.急呀

不过不幸中万幸是一个同事正好有一个连接还在上面,所以马上过去直接su - . 接下来的事大家都知道了, 所以搞得现在一提起要加数据文件,就怕得要死
做exp导出时,导到了user.dbf文件,还是生产库,结果生产服务器宕了3天才恢复好..【确认目录，很多操作最好到当前目录下，当前目录下的东西也要看清楚】偶遇到的严重事故：其实也不是人为造成的。9i的库，由于需要move tbs来降低HWM，然后再做alter index rebuild online，脚本连续跑了1个过月了，都没事情。某天突然发生问题，alertlog中无报错，应用访问数据库效率奇低，查了n多原因，未见异常，但是已经造成业务中断3小时。得到客户同意后，做完数据库全备，中午12点重启数据库解决该问题。-_-!!
事后发现其实在凌晨2点的时候有一个trc文件生成，看里面一堆的天书代码，发现类似一个object id，去查object id，object果然是被重建索引，估计是rebuild online的时候失败，到白天业务高峰期间smon还在清理临时段，因此业务堵塞。

另外一个省也是类似的事情，也是做rebuild online，但是估计中途失败了，再次做rebuild online的时候报错ora-8106的错误，按照oerr的指示，进行rename SYS_JOURNAL_nnnnn 表，数据库一下子猛报ora-600的错误，且切出来大量的udump文件，害怕了，重新rename回，600错误不再报，但是估计smon又开始忙活……8点开始业务高峰来了……再次堵塞……一个字：“等”!-_-!!到11点，smon清理完毕，恢复正常。

教训：（1）做rebuild online的时候一定要谨慎！！特别是大表的索引！（2）不要全信oerr的提示-_-!!
imp　错用了exp．结果把原来的dmp文件覆盖了．数据丢了．幸运的是数据不太重要．历史帐单数据，．一年刚好到期．可以封存了．　当时我很想告诉领导是我误操作．不过最后还是没有勇气去承认．人就是人．不是神．
最惨的一次是和公司的一个傻哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反

了一下,但是tnsnames没做修改,我准备重做备服的时候,使用了drop user cascade,把所有的用户都干了一

遍,刚刚干完,所有科室上夜班的护士小妹妹都给我打电话,说科室里的电脑全部不能用了,当时急的不行了,

还好习惯还不错,来的前一天做了一个全库冷备，立刻进行了恢复,不过也丢失了一整天的数据.
一个小时以后，所有的院领导以及信息科的工作人员都出现在我的面前，并质问我原因,我只能一脸无奈的

告诉他们刚刚来了只熊猫，那只熊猫烧了把香,然后数据就全丢了。然后给了他们一个卖瑞星的兄弟的电话,

那个兄弟连夜驱车200公里赶到目的地,到场以后首先确实了一下那个烧香的熊猫的存在,然后指出了那只熊

猫的巨大危害性，最后建议他们购买一套全院级的杀毒软件。大院长听取汇报后当即指示，立刻购买一套全

院级的杀毒软件，第二天一早就在购买合同上签字盖章.
这个事情造成四个后果,
第一,我在所有删除性操作以前都要核实一下对象的准确性,
第二,我从此拒绝和那个傻哥们一起出差，
第三，那个卖杀毒软件的兄弟会经常联系我，看看我有没有犯类似的错误。
第四，兄弟越多越好【看完后，狂汗】
一次误删了个表,最后恢复了,丢了一天数据.加了一晚上班,至今记得.
人越累的时候就越容易犯错误,我就是在最后快下班的几分钟犯的错误.
安装数据库的时候

su -
chmod 777 -R /oracle
多输入一个空格
chmod 777 -R / oracle
许多系统文件属性变坏
Unix瘫痪
这个错误犯了两次【chmod命令除了要注意敲进去的，如果对于目录进行，还要注意目录下是否有其他文件，不要想当然】
打patch,2个点开了4个窗口，两个用于操作，两个用于监控。
由于几天连续升级了很多点，这是最后的两个点了，胜利在望，大家思想也都松懈下来，我一边升级一边和旁边两个同事侃大山，
正侃着最近的美国大片呢，手工make的脚本一下子粘在了那个刚打完的那个点上，然后enter回车...........,于是又一次体验了指尖发麻、大脑空白
的感觉，后来一直在想吸毒是不是也是这种感觉啊【越是到最后关头，越是不能放松，要更加注意，否则功亏一篑】
刚换新东家的时候，入职第一天，服务部那听说开发部来了一个搞DB的，之后就马上过来找帮忙，说客户那边的查询很慢，需要解决方法。偶就做了一个优化脚本dbms_stats，加 index，很dw的做法。后来发现查询快了，但是整个业务流程慢了，又被投诉，原来还是业务＋查询混合使用的系统。

后来把index删除了，然后想了其它方法。

总结：在动DB之前一定要知道这DB的具体用途，在给DB加东西的时候，一定要多了解！！！很多人把DBA当作神，但自己不可忘记自己不是神，一定要切合实际，要深入到真实环境中！！！

而大伙说的查询系统是整个业务系统里的一个子系统，提供查询的，偶以为是DSS之类的查询系统。被经验误导，从此之后到任何DB的东西都问得清清楚楚。不动不熟悉的系统～
见过不少人在OEM／Toad中误击键盘删除用户或表空间的, 好象没人提啊. 估计犯这样错误的，后面还有更为严重的【GUI确实要警惕】
拷贝、粘贴语句很容易产生误操作。
有时dba自己也不知剪贴板是不是自己要执行的语句
很多的情况下还会出现你执行完copy操作后拷不出来语句的情况
比如从一个pdf文件拷一个你要执行的语句
没拷出来，而剪贴板中可能存在的是rm、truncate、drop这样的语句
如果语句再带上个;号及回车就更惨了。
提示：这样操作时记着把ultraedit或notepad打开，确认一下剪贴板中的内容

酒后操作、疲劳驾驶
提示：脑子真反应不过来时就别撑着了，歇一会，冲杯咖啡都不错。

其它提示：
1、做危险操作时最好拉上一个人，多一双眼睛会少很多危险。
2、如操作复杂且可能会影响到生产系统，最好把你的操作方案在测试环境测一下
3、最好不要白天做drop,truncate等危险操作，晚上即使做错也有补救时间
4、任何时侯做好备份对DBA都是非常非常重要的，特别的时侯真是救命的稻草。
5、我在生产系统要做drop表，除非十分确认是无用的表。不然都会先做rename操作，过一段时间再做drop操作。
经验：以后每次敲完命令，按回车之前，停一秒钟
mv、rm、shutdown、commit、truncate、drop、del、等操作之前，深呼吸，然后问问自己，你做的没错吧。
没错就回车吧。
一次TUXEDO服务出现严重堵塞，前台叫得又急。一看是数据库的TX锁堵塞，我查找堵塞别人的SESSION，然后找出它们的PID，在操作系统上直接KILL了，结果有一个是数据库核心进程（这个进程产生了TS类型的enqueue，而不是TX的enqueue，当时没有仔细看）。数据库马上DOWN了，吓出一身冷汗，马上重启数据库，重启服务，业务中断10分钟。
以后再怎么急，也要确认一下要KILL的SESSION是否是用户进程。
9i的 rac ，7x24 业务
删除一个分区表的分区时，没有加update global indexes,导致索引失效，
甲方要求用delete，组织按部分delete时，有个表千万的记录，和另外一个小表名字很像，结果大表删除时没有加条件限制，很久没有结束，然后终止，这时一个instance crash，不久另外一个crash。当时查了一下好像service guard有问题，非常想自己启动一下，还是没有做，让客户找小机工程师来看。
小机工程师也没有看出什么问题，重启后好了。

业务停止了2个多小时。

是做dba以来最惊心动魄的一夜。

教训就是：
充分准备，测试。

另外，看前面兄弟说的事情，很多是手误或者大脑不清醒。dba干活经常是深更半夜，而且有时是连续作战，到后面脑子肯定不好使了。所以我基本上有这么个习惯，在干活前先把步骤理一遍，具体到每一个命令。
如果有测试环境，先在测试环境做一下。

然后就照着这个step做，最好是复制粘贴。操作时，关闭其他所有shell窗口，将操作窗口的日志保存；
这样操作过程都可以记录，如果在操作过程中发生意外，意外都是不可知的，有大有小，有时比计划做的事情还麻烦。这样意外昨晚后，不至于漏掉要做的步骤，比如如果并行建索引，完了要改为非并行。总体操作是受控的。

事情完成了，写报告也比较方便。

非常赞同使用iso9000的管理方法：
记下要做的，
按所写的做，
写下所做的。
总结错误:
小心！细心！
养成好习惯！ sqlplus 里面使用 prompt 提示是那个数据库，避免操作错误， rm 前先ls pwd 看看，执行重大操作比如shutdown ,drop ,truncate 等操作都先hostname ,select instance_name from v$instance之类的检查
制定规范！！！流程，权限，以及 ddl trigger 等，操作尽可能作测试后再放到product
这个咚咚确实很恐怖，online rebuild我倒没碰见过问题，不过碰见过online create然后半路取消，呵呵，现象和这个差不多。这鬼东西确实恐怖！！rebuild online 中途主断确实非常可怕
Linux下，在文件系统没有卸载的情况下，使用fsck命令，导致文件系统损坏，所有数据全部丢失！
后悔了好几天。。。
有一次半夜被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这一行给屏弊掉。
有一次把dmp文件导到正式环境上了，应该是测试环境下的【操作前还是要确认机器】
一次做数据库的重建工作，按用户导出了所有的数据。
数据量挺大的，忙了很久。突然，脑袋发昏了，本来一个导入操作，鼠标粘贴出来了一个导出。结果一个大的dmp文件变成了0k。还好，有一个全库的导出在另外一个目录。教训就是：以后所有重要的导出数据，全部必须是400。【文件权限】
所以后来我再做事的时候，累了就不做，不会把测试和生产的数据库同时开着，做操作时再三看看是否进对了数据库。
我和他约法三章，以后测试环境和生产环境的user，sid，服务名都不能一样。又安排了一个计划，准备12月调整机房网络，单独让生产环境只和一个网段连，然后再用vpn连这个网段。。