#2
一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill,
则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了.
好的是库起来了,这个故障,我一直牢记于心.
现在做任何操作是,都要检查正确后再敲回车.

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

至今铭刻于心

#5
一次误删了个表,最后恢复了,丢了一天数据.加了一晚上班,至今记得.
人越累的时候就越容易犯错误,我就是在最后快下班的几分钟犯的错误.

#7
俺的

tar -cvf *.log

直接把前面几个online redo log tar进了最后一个online redo里面。。。幸好不是current的

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

幸好在30秒内就意识到了错误，及时中止了脚本的运行，只删除了一个无关紧要的用户

#10
我最惨，有一次把一个表一不小心给truncate了，上千万条记录一眨眼就没了；提心吊胆的陪了3天也没有把这个表搞定；最后不了了之了

#11
1、半夜加班，系统上线和数据迁移一起，在开始前进行了冷备文件，当上线和数据迁移要完的时候，
当时不知道怎么想的可能是半夜脑壳发昏，就在解压TAR把当前数据文件覆盖了，
辛好当时意识到了中止了解压，并且被覆盖的数据文件还没有数据。当时赶快把数据文件离线，删除，重建，不然要被旁边的同事海揍

2、如同前面8楼，最近复制粘贴很容易搞错窗口。辛好还没出大问题，不过已经深深警惕了

#13
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

#14
我的，开了两个PLSQL DEVELOPE窗口，一个生产的，一个非生产的，同名用户，同表空间名，结果非生产的建用户脚本在生产中跑了一下，
非生产是grant limit tablespace to XXX的，结果在生产中跑了以后，生产中的用户变成LIMIT了，结果程序出错，表空间不足。
导致应用出错半个小时后才处理好。
这个太惨痛了，建议所有的使用多个环境的人，并且操作多个PLSQL DEVELOPE的人尽量只开一个窗口操作，或者是操作生产的时候，用只读的查询用户。

#15
2004年一次下午17点左右在schema A 下一个表上增加一个字段(对于在schema A范围来说这个字段增加当时是不会有问题的)，
一加上去，系统load立即狂飙……
结果在schema B 下有一个包，里面有引用schema A 的这个表，没check倚赖关系以为A 和 B 之间没有联系，结果这个包编译不过去被大量进程尝试编译，
最后只有杀掉该相关应用所有进程重新连接才恢复。
这次故障导致我们一个无故障最长时间的团队免费去海南旅游三天的机会丧失。
当时的教训就是任何ddl的变化都需要check这个对象可能被引用的对象，
现在已经延伸到任何频繁被访问的sql了，基本频繁访问的应用要做ddl都要深夜才能做了。

#16
越是简单的事情越是容易犯错！
误操作往往就在不经意间产生

#22
當時，那幾天都是很疲勞的。在開發環境作數據文件分佈調整時，先cp完某個表空間所有文件到其他地方，然後作*匹配rm了此表空間在此目錄的數據文件。
但是rename時發現居然有一數據文件沒cp過來，忘了說了，此表空間是system表空間。
沒辦法，開發人員明天還要使用這個環境。幸虧之前有一備份，不過當時磁盤空間不是很充裕，足足折騰了一夜才搞定！
想起來都後怕哦，幸虧不是正式環境了！
再以後，就很少用cp,rm了，特別是rm *..,一般是此類操作用mv來完成。需要rm的東西，一般mv到一臨時目錄了，再rm了！
呵呵，可能都有點謹慎過頭了哦！

#23
业务系统升级，熬了两天两夜，最后的时候不知道按错那个键了（当时脑袋一片空白），全白费了，
幸好，有做笔记的习惯，脚本都整理好了，恢复重新做，1个多小时就搞定了：）。

#24
rm -rf /opt/ora92/* 在测试库中本来想删除数据库，结果错误的把ORACLE软件删除了．

郁闷啊,幸好不是生产库

#28
客户业务系统上线后由于存在部分性能问题，我对一个表作了dbms_stats....造成一个sql（涉及多个大表）执行计划改变(性能特差)主机基本瘫痪了两个小时。
最后给sql加hint才解决问题！

一个sql搞死一个数据库！

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

#30
偶的教训不是很深刻，不过意义很重大。
删除一些trace文件，然后就直接删除rm orcl*，结果通过vpn到生产的，网络太慢，命令刚刚慢慢的显示出来，
看都没看直接按回车，结果执行的命令却是rm orcl *，
因为orcl和星号中间有个空格，所以把这个目录下面所有的内容全部删除了。出了一身冷汗，试想，如过是删除数据文件目录下的内容，那立马死敲敲了

到现在为止，每次都要等命令完全显示出来，从头到尾看一遍再执行。
不过，大多数错误都是在很繁忙或者很疲劳的情况下发生的，呵呵，看来dba应该多休息才是。

#39
让我最难忘记的一次

我在一个表空间上添加一个数据文件,对于DBA来说是再平常再简单的不过一件事了, 可是由于添加一个数据文件,差点当机

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

不过不幸中万幸是一个同事正好有一个连接还在上面,所以马上过去直接su - . 接下来的事大家都知道了, 所以搞得现在一提起要加数据文件,就怕得要死

#40
你这个错误的确恐怖，哈哈，我也要记住别犯，我一哥们前一阵也是把根给弄满了，
当时我俩一起去做系统检查，他从一个卷复制文件到另一个卷，结过巧错了，弄到根卷了，
幸亏我也正连在上面，巧了我正改几个系统参数，一改发现改不了，提示没空间了，当时我的冷汗就下来了，
因为还在生产时间，根卷一满，os随时会 hang，数据库也玩玩了，脑子里急速回忆我是不是又干了什么白痴的事，想想今天很清醒啊，不可能阿，
赶紧检查，发现根里多了个目录，问他，果然是他弄来的，赶紧删了，没影响到系统，如果当时我不在或者没有在改那个参数，又是个事故，
埃，现在总结得出，任何生产库上的大操作，能等到晚上做最好晚上做，做的时候最好一个人干，一个人看，
两个人都确认了再回车，这样出问题的几率就小点……

至于我的误操作么，多了，从一开始的 update算法写错，把几千万的帐户蒸发掉（幸亏有备份，没有真的蒸发），到cd一个目录，敲错了没进去就开始rm，
或者做批量操作时候连的数据库多了，连这个数据库去做的时候没连对，跑到另外一个数据库执行了……，不敢回忆阿，
还好，我所有的都有备份，没有造成经济损失，不然我早就不用干这一行了，失败，现在年纪大了，才谨慎些了

#41
有一次ssh了n次

连接到了一个省平台，当时还以为在测试机上，执行了shutdown immediate
等了几秒钟没反应，马上意识到搞错了。

立即取消。

还好发现的早，没把数据库搞Down
以后制定了一系列规范防止这些低级错误

#44
在线移动数据文件,dd时把其他的覆盖了另外一个数据文件啊.

结果可想而知.从带库中花了几个小时才把这一个datafile恢复回来.还好有备份啊.

#45
记的最深的一次,业务判断逻辑出错导致sq写错l 后果就可想而知,数据出错，那都是钱来的
经过半个晚上的数据修复,终于搞好
现在写这些sql时很小心，很仔细，还让同事帮忙检查

#53
做exp导出时,导到了user.dbf文件,还是生产库,结果生产服务器宕了3天才恢复好..

#63
导入数据出错

将配置好用户配置要导入到生产库中，结果由于生产库中两个用户名太像，结果导到正在用的那个用户下，一堆存储过程失效，导致业务中断……

#66
tar cvf 后面两个参数写反了，结果前面的数据文件没了。

#72
我最蠢的一次是，刚刚接触oracle，还不知道备份恢复的概念，数据库运行在非归档，冷备时少了一个文件（别的同事做的备份），
过了几天恢复数据库，用当时的冷备恢复，结果数据库起不来，丢失的文件还包括很多重要应用字典数据，没办法，
重新输如这些字典数据，花了三天三夜。
还有几个月前，做测试，连到了生产库，把几个表空间删除了，出了一身冷汗！幸好是晚上，没有什么应用，及时恢复了数据库。

#74
偶遇到的严重事故：其实也不是人为造成的。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的提示-_-!!

#86
刚开始接触Linux tar -vzvf
tar -xzvf 后面的搞错了，备份全没了
马上重新备份，汗啊！

#89
最惨的一次是和公司的一个傻哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反

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

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

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

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

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

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

院级的杀毒软件，第二天一早就在购买合同上签字盖章.
这个事情造成四个后果,
第一,我在所有删除性操作以前都要核实一下对象的准确性,
第二,我从此拒绝和那个傻哥们一起出差，
第三，那个卖杀毒软件的兄弟会经常联系我，看看我有没有犯类似的错误。
第四，兄弟越多越好

#92
原来接手一个部门的所有数据库，结果漏了一个，也没人告诉我，所以我不知道这个数据库存在。
一天一个程序人员误按了一个按钮，把大量的数据全部删除，找到我后，发现数据库没有归档，也没有任何备份。
结果是程序人员补了几天的数据，我的奖金也直接泡汤

#93
和数据库无关，去客户那里做升级，白天交易时间（证券），由于不熟悉客户机房里设备的摆放，以为屏幕下的键盘就是这台主机的，
直接ctrl+alt+del启动（无盘站）结果这个键盘控制的是另外机架的主机，是乾隆转码机器，吓了一身冷汗，尽快重启。
教训：去客户那里一定先熟悉环境，最好和客户一起做。

#94
有一次大厦停电，通知半夜12点停电，我就懒得去动数据库了，没有备份，结果第二天早上，磁盘阵列启动不了了。
丢了周五一天的数据。我才发现：不能想当然的认为什么都不用做，这个错误让我更加记住了大家常说的：备份重于一切。呵呵……

#97
在cx700的存储navisphere管理界面,配置一个存储;同事接过去打开了生产环境另外一个存储的ie窗口;
我又接手过来,一恍惚看这个存储的配置与我打开的一样,就开始做删除STORAGE GROUP的操作;
还好我旁边另外一个同事看主机名不对,制止了我继续删除(我当时对他讲解了一下配置存储的步骤然后开始操作);
删除了lun就丢生产环境的crm数据了;
这个事情很可怕,那天人状态不怎么好; 以后做事情越是知道状态不好,越要加倍谨慎;
还有么,以前删除文件用相对路径来删除, ../path 方式,误删除了测试环境的oracle程序;(以后都用绝对路径了)
以前的错误都没有这次存储的错误可怕;

#103
RAW磁盤的連接文件, 整理的時候, 下RM命令加*, 把正在運行的一個實例的REDO LOG FLIE的連接文件刪除了.
當時就感覺出錯誤了. 那個實例當時還沒有DOWN. 還來切換REDO LOG時候找不到文件就DOWN了.
幸好RAC其他實例正常運行, 用戶和其他部門都沒有感覺到.
還來把那個連接文件重新建立, 又可以啟動了. 自此下RM命令很小心.

#108
我到是没有，不过以前俺们公司，有一个程序员写好的脚本，一个实施人员去执行，
脚本里面带了
delete * from xxx;
commit;
啥备份，归档都没有．

结果我们公司全部人员出动，
抱着笔记本，台式机，
去北京某区县所有的机关单位上门录了一星期人员信息．
至今记忆犹新．

#110
呵呵，哥们列举一次绝对毁灭性的操作：
重建表空间后文件系统里有些数据文件没有用了
我打算清理空间本来语句已经是这样写：
rm -rf ts_tab_test*
由于网络有延迟，导致了手欠，多敲了一个空格
写成了rm -rf ts_tab_test *
结果这个目录下所有的数据文件都被我删除了

绝对崩溃

#113
做DBA真有些不容易
有些时侯感觉是在练心里

一次领导问我好dba有啥条件，俺回答：
1、有兴趣，爱学习，爱思考
2、要有良好的心里素质，遇大事情不荒乱
3、要胆大心细
4、要有一个良好的习惯，如同过马路一样，一停二看三通过。

有过一次，我们的应用管理员为提高自已统计拥金语句的查询速度
自己自做主张在一张表上又建了一个索引
没过几分钟,tuxedo的队列就开始阻塞,前台营帐某一应用物别的慢
问一下应用管理员最近有什么变动，他回答说：没有
问题报到我这里，简单查一下，相应的应用几乎都在一条语句停留时间较长
看一下该语句的执行计划，发现走的索引不对
同时查了一下ddl trigger的log,发现应用管理员在几分钟前在这个表上建了一索引
drop掉新加的索引问题解决
应用管理员无语，领导发表了一通评论.

#114
俺有个同事也蛮搞笑的，一次在一个目录下发现有个*开头的文件，就写了个rm -rf *.后缀
结果可想而知了吧

#120
我有一次本来要删除测试库的，结果差点删除生产库的一个表的所有数据，还好强行ctrl_alt_delete，最后回滚了，哈哈，居然一条数据都没有删除。
确实是快下班，比较累。
以后不能在心急的时候维护数据库。

#131
安装数据库的时候

su -
chmod 777 -R /oracle
多输入一个空格
chmod 777 -R / oracle
许多系统文件属性变坏
Unix瘫痪
这个错误犯了两次

#134
看错数据库 truncate了几个关键业务表，当时电话不停的在耳边响，幸好没乱了方寸。
如果做不完全恢复代价太大，最后从log表中恢复了数据，没影响到生产，不过也出了一身冷汗，
从此做任何操作都很小心。

#136
我的一次，双机，os升级，先在备机上 update，patch什么的都打完后，在terminal里爽爽的敲reboot的时候发现把主机给起了。
冒冷汗的同时想起那个terminal是 telnet到主机上的...结果库还起不来，冷静地检查了一把，发现主机正跑着alter trablespace begin backup....，
赶紧把中断的备份都给end backup了，弄得现在一要重起都习惯性的先打hostname。

#137
我也说一下,刚进现在的公司不久,做一个数据仓库项目,同事周日加了一天班把数据抽到一个大表空间里,大概100G,第二天因为临时表空间增长很快,
决定重建,这个临时表空间的开头和那个大表空间名字是一样的,只是后面加了一个_temp,
当时也是因为事情比较多,认为这是很简单的,结果输入名字就忘了输入_temp,把大表空间删除了,
同事白加了一个星期天,虽然没影响什么进度(数据可以重抽),但这次教训是深刻的.

个人教训:
1.rm的时候一定不要用*之类的,要用的话要看好再用,否则会有意想不到的效果.
2.人在类的时候最容易出错误,所以每一次回车都要看好.

#142
打patch,2个点开了4个窗口，两个用于操作，两个用于监控。
由于几天连续升级了很多点，这是最后的两个点了，胜利在望，大家思想也都松懈下来，我一边升级一边和旁边两个同事侃大山，
正侃着最近的美国大片呢，手工make的脚本一下子粘在了那个刚打完的那个点上，然后enter回车...........,于是又一次体验了指尖发麻、大脑空白
的感觉，后来一直在想吸毒是不是也是这种感觉啊

#151
（05年的事）刚换新东家的时候，入职第一天，服务部那听说开发部来了一个搞DB的，之后就马上过来找帮忙，说客户那边的查询很慢，需要解决方法。
偶就做了一个优化脚本dbms_stats，加 index，很dw的做法。后来发现查询快了，但是整个业务流程慢了，又被投诉，原来还是业务＋查询混合使用的系统。

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

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

而大伙说的查询系统是整个业务系统里的一个子系统，提供查询的，偶以为是DSS之类的查询系统。
被经验误导，从此之后到任何DB的东西都问得清清楚楚。不动不熟悉的系统～

#152
删除日志时，输入rm * .log，因为星号*与log之间有空格，所以删除了该目录下所有的文件，吓得我出了一身汗

#153
使用EXP/IMP进行迁移时，没有看好里面得表，导致导入数据库中得数据全乱了

#156
测试库导入数据,不小心把正式库给drop了

#157
刚工作一年的时候，开发给了一段脚本就是给账户表某个字段修改长度（alter table account_t modify...），
我当时太累了，发了的脚本也没有说明何时操作，我就直接在生产库上执行了。
可想而知，大部分存储过程都失效，全省业务暂停2小时，嘿嘿。。。领导以后就给了我称号“破坏王”。

#159
truncate一张很大的表。。。

估计是人品好，CANCEL了一把，居然数据一点都没少。。。

#160
为了给员工做培训，我把正式库的数据导入到测试库上，但是不知道谁修改我机器上的盘点系统的配置文件，
结果显示的是测试库,实际上是正式库,IMP过程中其实已经表现异常了,但没意识到，
幸好,这个DMP的时间点只差2个小时,当时的中间的操作也没多少.

#161
另外一次说不上失误,但是影响很麻烦.

06年旧服务器上的数据库老是莫名其妙损坏,基本上1周2次,刚好有次恢复后，以为备份没有用了，就把备份,包括日

志文件也删除了，结果第3天又坏了，并且为了保证别的部门运行,我们把备份推后了,结果中间缺了一段,那次,安排

把数据补录进去，整整花了好几天晚上.

#163
主机和笔记本的oracle服务名一样，连接错误，通过业务程序把数据库给初始化了，那个惨

#169
想的还很周到

常出问题的有几种：
1、操作时主环境与测试环境没仔细看，疏忽了
2、用crt等终端软件连入主机操作时，不新开窗口，
   由一台主机去telnet另外一台主机，有时提示符并没有主机名
   一些人常常看看crt的标题而忽视了在哪台机器上
   从而命令在不该执行的机器上执行了。
   提示：每次telnet都用新的窗口，养成良好的习惯

3、拷贝、粘贴语句很容易产生误操作。
   有时dba自己也不知剪贴板是不是自己要执行的语句
   很多的情况下还会出现你执行完copy操作后拷不出来语句的情况
   比如从一个pdf文件拷一个你要执行的语句
   没拷出来，而剪贴板中可能存在的是rm、truncate、drop这样的语句
   如果语句再带上个;号及回车就更惨了。
   提示：这样操作时记着把ultraedit或notepad打开，确认一下剪贴板中的内容

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

其它提示：
1、做危险操作时最好拉上一个人，多一双眼睛会少很多危险。
2、如操作复杂且可能会影响到生产系统，最好把你的操作方案在测试环境测一下
3、最好不要白天做drop,truncate等危险操作，晚上即使做错也有补救时间
4、任何时侯做好备份对DBA都是非常非常重要的，特别的时侯真是救命的稻草。
5、我在生产系统要做drop表，除非十分确认是无用的表。不然都会先做rename操作，过一段时间再做drop操作。

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

#177
mv、rm、shutdown、commit、truncate、drop、del、等操作之前，深呼吸，然后问问自己，你做的没错吧。
没错就回车吧。

#183
我就是犯了類似的錯誤，把system01.dbf給壞了一部分！盡管馬上按ctrl+c,
還好是EBS剛准備上線的那一次,幸好有前一天的冷備！

那次知道了，為什麼DBA一定要有經驗的！
做DBA不光是只要技朮的,心態和性格很重要！

#185
没有作任何备份,把系统格了....

丢失公司门户网站近半年的各类数据

#187
我最难忘的： root 用户在根目录下 rm -rf abc *，abc 和*之间有个空格，结果把os删除了。
已经成为佳话。
什么事情都可能发生的。
好像就是05年的今天搞的。

从此，整个人好像变了一样，做什么事情，都三思而后行了。

#188
也是开了多个窗口，一个窗口建库，另一个窗口是生产的库。搞错了，在生产的服务器上直接shutdown了，立刻电话就上来了。
好在没有造成太大影响，也是提心吊胆的。多窗口危险很大！！！

#189
在公司生产系统目前还没有误操作，估计有一回就该换人了

有的一次是在上海IBM 实验中心做RAC性能的测试（环境都是我们自己搭的）
当时我在用DD测试一个LV读写速度的时候，没很在意具体LV对应的情况
做完以后意识到这个LV已经被数据库使用了
回头ALERT看
晕
居然是SYSTEM用的LV
那次时间以后导致测试进度延迟一天
还好没有太麻烦IBM的兄弟
要不NND不好交待了啊

回到生产以后
日常维护不用有写权限的用户登陆
有类似要求操作
多拉个兄弟一起看着

#192
记忆深刻的一次是

grep rman- backup.log >> backup.log。

初学shell的时候，想把backup.log中的rman-类型的错误，都放到backup.log最下面。
这个脚本，一般情况下，也没有问题。
但是，文件中数据一多，问题来了，因为并不是先全部过滤后写文件的，是一边过滤一边写，追加的信息马上就再追加，文件一下就把/home目录给占满了。

最近的一次，很寒
瞒自信的把一个机器的电源拔了，结果拔错了。。。。

错误犯了很多，不一一说了。

#198
check一张表被哪些对象使用，用什么方法呢。有什么SQL可以查看的？呵呵，谢谢了
记得有一次Create index也造成类似的问题。所以许多操作都要放在晚上才行。
--------------------------------------------------------------------------------
可以用這個︰
/* Formatted on 2007/12/05 11:41 (Formatter Plus v4.8.7) */
SELECT              SELECT     object_id
                FROM public_dependency
          CONNECT BY PRIOR object_id = referenced_object_id
          START WITH referenced_object_id =
                        (SELECT object_id
                           FROM SYS.dba_objects
                          WHERE owner = '%'
                            AND object_name = '%'
                            AND object_type = '%')
ddl完了記得對有依賴關係的pl/sql對象recompile。

俺最慘的一次是上了１０几個小時夜班後正準備下班，點進VM執行init 0，
卻忘記有從這個VM窗口 telnet到生產環境cp參數文件而且等數據庫狀態監控報警後才反應過來...
還好是RAC，但也造成不小影響，從此下任何指令前先CHECK過。

另外個人總結在unix下盡量用tab得到文件名和路徑名有助于避免空格錯誤。

#207
一个省级数据库，那时候我才没学oracle多久，然后就我一个人在机房。
那是一台windows的服务器，我不知怎么想的，就在服务器上用 windows优化大师清理了一下注册表。
因为是晚上，我清完以后重启了一下服务器，然后那个oracle的监听服务就启不起来了，
当时就吓的我一身汗，后来发现我用rman target / 是可以连接到数据库的，才知道问题不大。
最后发现原来是优化大师把注册表中listen的服务的一些键值给删除了，后来手工加上就又好了。
从这次问题以后我就对windows优化大师再也不感兴趣了。

#208
一次TUXEDO服务出现严重堵塞，前台叫得又急。一看是数据库的TX锁堵塞，我查找堵塞别人的SESSION，然后找出它们的PID，在操作系统上直接 KILL了，
结果有一个是数据库核心进程（这个进程产生了TS类型的enqueue，而不是TX的enqueue，当时没有仔细看）。
数据库马上DOWN 了，吓出一身冷汗，马上重启数据库，重启服务，业务中断10分钟。
以后再怎么急，也要确认一下要KILL的SESSION是否是用户进程。

#210
9i的 rac ，7x24 业务
删除一个分区表的分区时，没有加update global indexes,导致索引失效，
甲方要求用delete，组织按部分delete时，有个表千万的记录，和另外一个小表名字很像，结果大表删除时没有加条件限制，很久没有结束，然后终止，
这时一个instance crash，不久另外一个crash。当时查了一下好像service guard有问题，非常想自己启动一下，还是没有做，让客户找小机工程师来看。
小机工程师也没有看出什么问题，重启后好了。

业务停止了2个多小时。

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

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

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

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

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

非常赞同使用iso9000的管理方法：
记下要做的，
按所写的做，
写下所做的。

#215
在LINUX下输入了FSCK直接回车敲了几下，导致LINUX系统挂掉，数据库也一样的挂了

#216
05年一次做了一夜火车后直接到公司就遇到故障，重起数据库报错，数据文件找不到了，晕乎乎的就写了一个脚本准备offline 然后恢复，
但是文件名字是从文档中copy出来的，结果copy串行了，幸好offline 这一步就发现了，出了一身汗，手都发抖了。
而且后来发现数据文件找不到是因为双机切换的时候一个卷没有同步过来

07 年 DG维护， switch over ， ip 也switch了但是忘了修改 listener.ora 结果原来的primary 上操作lsnr 的时候把新的primary 的lsnr停掉了。

别人的错误，truncate 表，drop 表，错误dbms_stats

总结错误:
小心！细心！
养成好习惯！ sqlplus 里面使用 prompt 提示是那个数据库，避免操作错误， rm 前先ls pwd 看看，
执行重大操作比如shutdown ,drop ,truncate 等操作都先hostname ,select instance_name from v$instance之类的检查
制定规范！！！流程，权限，以及 ddl trigger 等，操作尽可能作测试后再放到product
希望大家都说说好的避免错误的措施，避免睡不好觉

#225
靠，我前2天想对一个操作 ,进行跟踪，但是找不到他的sid,后来弄了个system级别的跟踪，因为应用是tuxedo,长连接.
第二天客户udump小的日志20G,搞的数据库hang住了。哎,这个真的要小心。

#234
当时刚毕业，还是再做程序员，因为程序升级，导致数据库表和seq也有些变化，用insert into() select * from A这样的语法按时间导入到新的表中，
因为对between and的理解模糊，导致少了一天的记录，是某部机关的日志信息，我是一个月一个月导的，所以每个月的最后一天信息都没有导入，
我自信满满的把原表 truncate掉了，后来项目经理细心，发现少记录了，把我很K了一次......

#235
一不小心把UPS的关了，导致主机停电，幸好数据库可以正常启起来

#244
有一次半夜被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这一行给屏弊掉。

#255
一次在AIX下给客户rename datafile，文件太多，弄到windows下用excel编辑，然后做个脚本去rename，结果有两个数据文件名字相同，
大小写不一样，在 execel里为了文件名清晰，用了个UPPER函数，rename以后，mv 脚本就把其中一个覆盖掉了，还好有备份，回复了5个小时。
之后再也不敢用excel做这些脚本了。

#258
一次做数据库的重建工作，按用户导出了所有的数据。
数据量挺大的，忙了很久。突然，脑袋发昏了，本来一个导入操作，鼠标粘贴出来了一个导出。结果一个大的dmp文件变成了0k。
还好，有一个全库的导出在另外一个目录。教训就是：以后所有重要的导出数据，全部必须是400。

#264
RAC环境，dd裸设备的时候，本来只打算清空data diskgroup的，结果不小心清空了所有raw disk，ocr和vt当场挂掉了，
不过是测试环境，哈哈，要是prod我可以直接卷铺盖走人

#266
尤记得那年我还很冲动，测试环境中发现表空间不够了，就加了一个文件。一会有人打电话说生产库总报一个提示。
马上去看，发现我的数据文件竟然加在生产库上！而且路径类似windows的，非常奇怪，冷汗！
靠，原来写错tns串了，见鬼的是测试环境和生产环境网络竟然是互通的！
生产环境是rac，裸设备，9i……后来只好把这个本地文件脱机，数据倒没有丢失，但总有个删不掉的脱机文件！
好在用户还很傻，不知道发生了什么，后来找个理由升级成10g了，
我心里的石头才算放下了。
从此以后我从来没有犯错。

#273
开了多个窗口，把生产库里面最重要的表truncate了，本来想truncate测试库的。

这下子，惨了。。。
还没备份。。。
一个礼拜都不好意思。

#274
一次在ibm p570上安装rac，由于客户网络有问题，结果失败，在
删除rac时rm -inittab*.crsd等几个rac的启动文件，一不留神吧AIX的一个文件删了，结果系统起不来了。
后来多亏ibm的工程师恢复了系统。结果晚上3点才收工。

#275
第一件：想truncate测试库的数据，结果成正式库了。
第二件：晚上迷糊糊的把DG的主库写成READONLY了。最后第二天业务系统登录不进去了都（幸好是测试阶段）
第三件：想把某一普通用户下的表全部删除，结果登录的是SYSTEM。。。后果可想而知。。。。。

#283
最近一次是需要新建一个用户测试环境，当时没看清要求，结果数据导入的是另外一个环境的数据，
而中间件又是其他一个环境的中间件，其中数据结构基本一样，数据也是一些不一样。
然后用户开始测，测试了20天，过后发现有些功能不对啊，然后查出来是中间件数据库不一致，然而数据库是我导入的数据，就是这里导错了。
也不能重新建立环境了，用户已经测试了20天了，当时郁闷得要死，被老大还算客气的教育了一下，最后保留数据库，换了中间件，
还有一次我登陆了生产用户没退出来，然后自己做测试，写PL/SQL，还贴到生产上面去执行了，
过后发现是生产环境，马上检查脚本，还好只是一些输出的脚本，没有DML，后来想起来，真的很怕。
我还删除过UAT环境的中间件，就是rm -rf,现在我喜欢用rm -ir...........,或者很小心。。
教训就是一定要小心，要清醒，看3遍在做。。。用完生产环境就马上退出来。。

#284
在我接触oracle的第一个月整垮了一个数据库
当时对备份和恢复没有任何概念
一个新系统中午上线的，然后下午6点开发人员的存储过程有问题，误更新了一张表，需要帮他们恢复数据。
数据库是处在归档模式，当时不知道闪回表为何物，更是不知道Rman位何物.只记得当时慌慌张张的去网上查资料，也没搞出个所以然来！
我忽然想起3点半我做了一个备份，心想能恢复到3点半也不错啊！
shutdown数据库，呵呵当时居然还知道shutdown还原！覆盖备份的数据文件！
startup数据库，报600错误，当时不知道600为何物，还有一大串的[][][][][]和数字。
心想应该是覆盖有问题吧！又重新覆盖了一遍，这次是连安装目录一起覆盖，妈的，居然还是ora-600，
一些表居然可以查询出来，想exp出来，一导出就报错，数据库就关闭了！就这样启动关闭往往复复！搞到凌晨一点也没搞定。丢了6个小时的数据。
最终数据库都起不来了!第二天重建！
第二天开发人员去仓库手动恢复数据，一条条的补，搞了两三天吧！

过了N天才明白当时的备份是错误的，我是在数据库启动的情况下复制数据文件的，不知道这算是冷备还是热备！反正是不能恢复的备！
又过了N天又明白了用闪回是能多么轻易的恢复数据！懊悔啊！

现在我明白了，没把握，就别动他，先确定，再行动。

#286
一个db2数据库，前台程序挺烂，经常需要我delete from table where 操作。
那天早上一到，还没进入工作状态，接了个电话需要删除些记录，晕了头了后面忘记加where条件了,
一个关键表数据没了，紧接着电话一个接一个的打来。还好生产库－查询库是做了数据复制的，几分钟后把数据同步回来了。
如果再晚上几分钟查询库同步一次数据也没了。后来想想还是很担心，再后来没有出过大错误了。

#288
入行一年多的时候，有次扩测试环境数据库程序和数据所在卷空间的时候没经验，按了ctrl+c，卷丢失，重建卷，安装程序，恢复数据，
12个小时，那天也是13号，从下午2点搞到凌晨2点

posted on 2015-12-10 23:29 美丽de世界阅读(782) 评论(0) 编辑收藏举报

刷新页面返回顶部

公告

导航