楼主: yxyup

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

[复制链接]
论坛徽章:
19
授权会员
日期:2007-08-25 20:02:41会员2007贡献徽章
日期:2007-09-26 18:42:10BLOG每日发帖之星
日期:2008-11-13 01:01:05
发表于 2007-12-15 20:45 | 显示全部楼层
人越累的时候就越容易犯错误.  事实如此。所以大家得注意休息。

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 21:47 | 显示全部楼层
原帖由 biti_rainy 于 2007-12-15 10:01 发表
2004年一次下午17点左右在schema  A 下一个表上增加一个字段(对于在schema  A范围来说这个字段增加当时是不会有问题的),一加上去,系统load立即狂飙……结果在schema B 下有一个包,里面有引用schema  A 的这个表,没check倚赖关系以为A 和 B 之间没有联系,结果这个包编译不过去被大量进程尝试编译,最后只有杀掉该相关应用所有进程重新连接才恢复。这次故障导致我们一个 无故障最长时间的团队免费去海南旅游三天的机会丧失。当时的教训就是任何ddl的变化都需要check这个对象可能被引用的对象,现在已经延伸到任何频繁被访问的sql了,基本频繁访问的应用要做ddl都要深夜才能做了。



看来这应该是biti大师最难以忘怀的一次了.

这是我第二次听到biti说起这件事了,第一次是在OU亲耳听到的

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 21:48 | 显示全部楼层
原帖由 bq_wang 于 2007-12-15 00:31 发表
我最惨,有一次把一个表一不小心给truncate了,上千万条记录一眨眼就没了;提心吊胆的陪了3天也没有把这个表搞定;最后不了了之了



算你Y走运哦

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 21:53 | 显示全部楼层
原帖由 Toms_zhang 于 2007-12-15 10:07 发表
自养猪以来,个人尚未犯过人为的失误.
今后是否继续养猪,还是个问题,所以只能遗憾的说:我没有过类似经历,太遗憾了!



像老兄这样,估计在DBA生涯时,也难以如愿

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 21:56 | 显示全部楼层
原帖由 warehouse 于 2007-12-15 15:22 发表
平时没机会在生产库上犯错误,偶尔出去解决故障时也是谨慎再谨慎,小心再小心


遗憾,遗憾啊,建议谢兄下次找客户那里找个机会,也搞一个难以忘怀,然后再来这里登记

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 21:57 | 显示全部楼层
原帖由 WESTLIFE_XU 于 2007-12-15 18:51 发表
不小心用rm -rf /home目录下的所有文件,/home目录下放的账务系统的app。一看删除的路径的不对,已经来不及了。



有第一次了,不错,不错

使用道具 举报

回复
论坛徽章:
33
ITPUB元老
日期:2009-03-11 15:35:03咸鸭蛋
日期:2011-11-06 22:20:25紫蛋头
日期:2011-12-27 22:15:052012新春纪念徽章
日期:2012-01-04 11:49:542014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11红宝石
日期:2014-06-03 13:13:19
发表于 2007-12-15 22:02 | 显示全部楼层
刚刚开始接触的时候,把数据文件直接删除了,呵呵

使用道具 举报

回复
认证徽章
论坛徽章:
106
2008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:222012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25版主4段
日期:2012-05-15 15:24:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:07:31
发表于 2007-12-15 22:16 | 显示全部楼层
原帖由 NinGoo 于 2007-12-14 23:36 发表
BS楼主,砖都不抛一个就来引玉



让我最难忘记的一次

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

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

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

使用道具 举报

回复
论坛徽章:
19
生肖徽章:羊
日期:2006-09-06 21:18:482012新春纪念徽章
日期:2012-01-04 11:51:22ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15CTO参与奖
日期:2009-02-12 11:45:48生肖徽章2007版:龙
日期:2008-12-16 14:04:41奥运会纪念徽章:篮球
日期:2008-10-24 13:29:38奥运会纪念徽章:沙滩排球
日期:2008-07-02 12:09:31生肖徽章2007版:鼠
日期:2008-01-02 17:35:53ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44会员2007贡献徽章
日期:2007-09-26 18:42:10
发表于 2007-12-15 22:56 | 显示全部楼层
原帖由 yxyup 于 2007-12-15 22:16 发表



让我最难忘记的一次

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

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

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



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

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

使用道具 举报

回复
论坛徽章:
19
生肖徽章:羊
日期:2006-09-06 21:18:482012新春纪念徽章
日期:2012-01-04 11:51:22ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15CTO参与奖
日期:2009-02-12 11:45:48生肖徽章2007版:龙
日期:2008-12-16 14:04:41奥运会纪念徽章:篮球
日期:2008-10-24 13:29:38奥运会纪念徽章:沙滩排球
日期:2008-07-02 12:09:31生肖徽章2007版:鼠
日期:2008-01-02 17:35:53ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44会员2007贡献徽章
日期:2007-09-26 18:42:10
发表于 2007-12-15 23:02 | 显示全部楼层
原帖由 netbanker 于 2007-12-15 07:01 发表
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


这个也非常赞同阿,有些脚本就是炸弹

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,7折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时七折期:2019年8月31日前


----------------------------------------

大会官网>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表