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

不断的看到很多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.eygle.com/archives/2006/04/dba_warning_truncate.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23650854/viewspace-681812/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23650854/viewspace-681812/