楼主: yxyup

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

[复制链接]
论坛徽章:
68
2015年新春福章
日期:2015-03-06 11:57:31奥运会纪念徽章:手球
日期:2012-09-13 15:50:49奥运会纪念徽章:水球
日期:2012-08-26 20:46:49版主1段
日期:2012-05-15 15:24:112012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-01-04 11:49:54
发表于 2007-12-15 06:52 | 显示全部楼层
原帖由 bq_wang 于 2007-12-15 00:31 发表
我最惨,有一次把一个表一不小心给truncate了,上千万条记录一眨眼就没了;提心吊胆的陪了3天也没有把这个表搞定;最后不了了之了


  

使用道具 举报

回复
论坛徽章:
68
2015年新春福章
日期:2015-03-06 11:57:31奥运会纪念徽章:手球
日期:2012-09-13 15:50:49奥运会纪念徽章:水球
日期:2012-08-26 20:46:49版主1段
日期:2012-05-15 15:24:112012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-01-04 11:49:54
发表于 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

使用道具 举报

回复
论坛徽章:
9
数据库板块每日发贴之星
日期:2006-09-06 01:01:55数据库板块每日发贴之星
日期:2006-09-07 01:02:41数据库板块每日发贴之星
日期:2006-09-23 01:02:09数据库板块每日发贴之星
日期:2006-09-26 01:03:58数据库板块每日发贴之星
日期:2006-10-06 01:02:42数据库板块每日发贴之星
日期:2006-10-08 01:02:15数据库板块每日发贴之星
日期:2006-10-09 01:02:43授权会员
日期:2006-12-23 10:14:58会员2007贡献徽章
日期:2007-09-26 18:42:10
发表于 2007-12-15 07:16 | 显示全部楼层
我的,开了两个PLSQL DEVELOPE窗口,一个生产的,一个非生产的,同名用户,同表空间名,结果非生产的建用户脚本在生产中跑了一下,非生产是grant limit tablespace to XXX的,结果在生产中跑了以后,生产中的用户变成LIMIT了,结果程序出错,表空间不足。导致应用出错半个小时后才处理好。
这个太惨痛了,建议所有的使用多个环境的人,并且操作多个PLSQL DEVELOPE的人尽量只开一个窗口操作,或者是操作生产的时候,用只读的查询用户。

使用道具 举报

回复
论坛徽章:
86
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-01-04 11:49:542012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20咸鸭蛋
日期:2012-05-08 10:27:19版主8段
日期:2012-05-15 15:24:112013年新春福章
日期:2013-02-25 14:51:24
发表于 2007-12-15 10:01 | 显示全部楼层
2004年一次下午17点左右在schema  A 下一个表上增加一个字段(对于在schema  A范围来说这个字段增加当时是不会有问题的),一加上去,系统load立即狂飙……结果在schema B 下有一个包,里面有引用schema  A 的这个表,没check倚赖关系以为A 和 B 之间没有联系,结果这个包编译不过去被大量进程尝试编译,最后只有杀掉该相关应用所有进程重新连接才恢复。这次故障导致我们一个 无故障最长时间的团队免费去海南旅游三天的机会丧失。当时的教训就是任何ddl的变化都需要check这个对象可能被引用的对象,现在已经延伸到任何频繁被访问的sql了,基本频繁访问的应用要做ddl都要深夜才能做了。

[ 本帖最后由 biti_rainy 于 2007-12-15 10:18 编辑 ]

使用道具 举报

回复
论坛徽章:
59
狮子座
日期:2016-03-26 13:35:402013年新春福章
日期:2013-02-25 14:51:24双黄蛋
日期:2013-02-25 11:06:15ITPUB 11周年纪念徽章
日期:2012-10-09 18:06:20灰彻蛋
日期:2012-04-25 13:19:33紫蛋头
日期:2012-03-14 11:16:09最佳人气徽章
日期:2012-03-13 17:39:18玉石琵琶
日期:2012-02-21 15:04:38鲜花蛋
日期:2011-11-30 14:13:01ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15
发表于 2007-12-15 10:06 | 显示全部楼层
越是简单的事情越是容易犯错!
误操作往往就在不经意间产生

使用道具 举报

回复
论坛徽章:
112
2008新春纪念徽章
日期:2008-02-13 12:43:03马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14马上有车
日期:2014-11-03 12:40:39沸羊羊
日期:2015-03-04 14:43:432015年新春福章
日期:2015-03-06 11:57:31慢羊羊
日期:2015-03-09 16:15:39
发表于 2007-12-15 10:07 | 显示全部楼层
自养猪以来,个人尚未犯过人为的失误.
今后是否继续养猪,还是个问题,所以只能遗憾的说:我没有过类似经历,太遗憾了!

使用道具 举报

回复
论坛徽章:
114
授权会员
日期:2005-10-30 17:05:332013年新春福章
日期:2013-02-25 14:51:24奔驰
日期:2013-08-01 21:18:36宝马
日期:2013-12-04 21:52:282014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14
发表于 2007-12-15 10:21 | 显示全部楼层
没有

使用道具 举报

回复
认证徽章
论坛徽章:
139
2009日食纪念
日期:2009-07-22 09:30:00ITPUB8周年纪念徽章
日期:2009-09-27 10:21:21祖国60周年纪念徽章
日期:2009-10-09 08:28:002010年世界杯参赛球队:葡萄牙
日期:2010-01-18 09:23:302010年世界杯参赛球队:意大利
日期:2010-01-21 07:30:192010年世界杯参赛球队:南非
日期:2010-01-22 09:48:242010年世界杯参赛球队:加纳
日期:2010-02-13 16:34:422010新春纪念徽章
日期:2010-03-01 11:04:572010年世界杯参赛球队:斯洛伐克
日期:2010-05-21 11:24:312010年世界杯参赛球队:塞尔维亚
日期:2010-06-30 13:43:14
发表于 2007-12-15 10:55 | 显示全部楼层
看起来损失都不行。
我最惨的一次是忘记把开发设置在参数文件中的nologging参数取消了。
结果数据库上线后发生了一次网络风暴,所以机器全搞死了,重启後每一台数据库能起来。
详见俺的精华贴

使用道具 举报

回复
论坛徽章:
31
NBA常规赛纪念章
日期:2008-04-18 19:48:162011新春纪念徽章
日期:2011-02-18 11:43:36ITPUB十周年纪念徽章
日期:2011-11-01 16:21:152012新春纪念徽章
日期:2012-01-04 11:51:22
发表于 2007-12-15 11:00 | 显示全部楼层
原帖由 hihiw 于 2007-12-14 23:33 发表
一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill,
则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了.
好的是库起来了,这个故障,我一直牢记于心.
现在做任何操作是,都要检查正确后再敲回车.



曾经犯过一个类似的错误,将永生铭记!

使用道具 举报

回复
论坛徽章:
70
ITPUB元老
日期:2007-07-19 08:57:15乌索普
日期:2016-06-24 14:29:16沸羊羊
日期:2015-02-12 09:15:562014年世界杯参赛球队:喀麦隆
日期:2014-05-20 16:06:36马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11迷宫蛋
日期:2013-04-24 13:52:55茶鸡蛋
日期:2013-04-19 13:54:282013年新春福章
日期:2013-02-25 14:51:24蛋疼蛋
日期:2013-02-19 14:05:00
发表于 2007-12-15 11:02 | 显示全部楼层
备份的时候把复制搞成剪切了

使用道具 举报

回复

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

本版积分规则 发表回复

PostgreSQL中国大会,参会票抢购!

由 PostgreSQL中文社区与ITPUB联合主办的第九届《PostgreSQL 中国技术大会》将在北京隆重召开。PostgreSQL 作为功能最强的的开源关系型数据库之一,得到了越来越多企业的推广和运用,也越来越受到广大技术爱好者的欢迎和重视。这将是 PostgreSQL 的又一次交流盛会。
----------------------------------------
时间:2019年11月29~11月30日

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