« 致命的人为错误 »
DBA » http://www.anysql.net/dba/fatal_human_errors.html 2008-03-14在所有的错误中, 人为错误是最难恢复的, 尤期是要到达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实在要小心, 如果觉得头晕, 直接告诉领导, 换个人做工作!


有个人在Toad中编辑表结构,需要加列,结果一不小心,先删除了一列,再将这一列加上去,将要加的列加上去,保存后,发现那个列的数据都没了.
因为Toad做了两件事, 首先删除一列,然后再加了两列.
第三种情况在我以前的公司项目部的兄弟干过
先exp,然后drop,然后imp
发现exp的文件错误了,没辙了.
那怎么不找AUL呢?
David.Guo Says:
2008-03-14 at 16:45
第三种情况在我以前的公司项目部的兄弟干过
先exp,然后drop,然后imp
发现exp的文件错误了,没辙了.
anysql Says:
2008-03-14 at 17:32
那怎么不找AUL呢
哈哈