致命的人为错误

作者: AnySQL.net, 转载时请务必以超链接形式标明文章原始出处和作者信息.
链接: http://www.anysql.net/dba/fatal_human_errors.html

    在所有的错误中, 人为错误是最难恢复的, 尤期是要到达99.9%的恢复, 最近就有三个这样的例子.

    一个国外的200G的数据库, 使用的是Oracle ASM, 有一天突然起不来的, 上去看了后, 居然是将一块ASM中的盘加到了操作系统的卷管理系统中了, 因此硬盘上部分数据被覆盖, 导致了Oracle ASM起不来. 后来找来找去, 说是有一个dmp格式的备份, 接近200GB, 这么大的dmp文件能成功导入的可能性很少了, 果然, 导入35GB的数据后, imp报错了. 最后的结果可想而知, 从这里可以看出文档(要指明那块盘被那个系统使用了), 方法(加盘前检查一下有没有正被别的系统使用)和简单性(同一台机器用ASM和OS VG做什么呢?)的重要性.

    第二个例子, 人家用PL/SQL Developer工具以DBA权限登录, 一不小心选中了所有用户选项, 然后按了删除操作, 虽然发现后按了取消键, 并强行关闭数据库, 还是导致了上百个表被删除. 在删除的过程中, 又有部分数据进入到系统中, 因此不能全部恢复, 还导致了LOB索引损坏, 总算运气不错, 还恢复了大部份数据. 想想有多少DBA能离开图形工具这个话题, 还是有讨论的必要性的. 建议Toad等图形工具禁用大量删除功能算了, 带来的方便性远没有危害性多.

    第三个例子, exp后将原来表删除了, 然后再imp到其他数据库时, 发现字符集有问题了. 如果真的是exp时出错了, 很多数据将要变成乱码了, 这只能说是人为错误, 谁让他们不检查exp时的字符集呢?

    做DBA实在要小心, 如果觉得头晕, 直接告诉领导, 换个人做工作!

根据标签搜索:

进行网络收藏:

Posted on Mar 14, 2008 2:59 PM | | DBA

留言 (3)

有个人在Toad中编辑表结构，需要加列，结果一不小心，先删除了一列，再将这一列加上去，将要加的列加上去，保存后，发现那个列的数据都没了.

因为Toad做了两件事, 首先删除一列，然后再加了两列.

Posted by anysql | Mar 14, 2008 3:39 PM

第三种情况在我以前的公司项目部的兄弟干过
先exp,然后drop,然后imp
发现exp的文件错误了,没辙了.

Posted by David.Guo | Mar 14, 2008 4:45 PM

那怎么不找AUL呢?

Posted by anysql | Mar 14, 2008 5:32 PM

发表留言:

« Previous | Main | Next »

英语900句 | English 900

  • Hi, Joe, is it really you?
    • 乔, 你好, 真是你吗?
  • Hi, Ann. Nice to see you again.
    • 安, 你好. 真高兴再次见到你.
  • It's been a whole year since I last saw you.
    • 我整整一年没见你了.
  • Yes, but you look as pretty now, as you did then.
    • 但你看起来还是那么漂亮.
  • Oh, thank you. How have you been these days?
    • 欧, 谢谢. 这段时间你好吗?