暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

DBA警世录:Truncate之生产与测试环境

原创 eygle 2006-04-25
537

不断的看到很多DBA在学习或工作过程中犯过很多相同或相似的错误.忽然想到,如果我把这些常见的错误或者故障收集记录下来,做为《警世录》,那么大家是不是可以做为借鉴,并使得后来人少犯或者不犯这些错误呢?


这就是DBA警世录的由来.


今天看到有朋友记下了这样一个案例:



因为要导两个表的数据到测试库,结果在产品库上用了Truncate......
更糟的是客户首先发现了问题 而不是自己 自己以为目标是
测试库............


总结:
1. 谨慎&细心
操作涉及产品库慎之再慎
2. 产品库和测试库有相同的user/pw(这在某种程度上造成了假象)


ps:此次事件被定性为生产事故 严重



这样的案例很多见,因为测试环境和生产环境混淆而导致的误Delete,误Truncate操作经常发生。除了DBA不够严谨之外,制度上没有保证也是问题之一。


这位同学总结的很好,通常我们的测试库和产品库应该设置不同的用户密码,不同的SID,在进行重要操作时,应该先select instance_name from v$instance命令验证一下当前连接的例程:









SQL> select instance_name from v$instance;


INSTANCE_NAME
----------------
eygle



这就如同我们在Unix/Linux主机上应该经常用hostname来确认一下当前连接的主机一样。


如果在本地登陆,我们还可以通过修改本地glogin.sql文件,显示当前连接的实例等信息。


总之,在执行任何数据变更操作之前,我们都应当谨慎。这是对于DBA的基本要求之一。


参考连接:
生产事故 http://www.itpub.net/533262.html  


 

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论