eygle.com   eygle.com
eygle.com  
 

« 我的写作进度之二 | Blog首页 | DSI系列教材 纷纷现身江湖 »

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

作者:eygle |【转载时请务必以超链接形式标明文章和作者信息及本声明
链接:

不断的看到很多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  

 

By eygle on 2006-04-25 10:31 | Comments (1) | Posted to Beginner | Edit |Pageviews:

相关文章 随机文章
  • DBA警世录:谨慎操作数据字典
  • 成功恢复案例:解决字典表误Truncate故障
  • DBA警世录:职业生涯误操作之误删除篇
  • ITPUB年会回顾-阿里巴巴的数据库管理优化体系
  • DBA警世录:有些习惯DBA需要养成
  • What's mean ORA-25191?
    经典图书推荐系列-之六
    ITPUB 2007年会 相聚北京香山饭店
    Oracle HowTo:如何获得数据库的DBID
    《Oracle数据库性能优化》一书即将出版
    网上相关主题:
    Google

    留言 (1)

    如果在本地登陆,我们还可以通过修改本地glogin.sql文件,显示当前连接的实例等信息。
    ——曾经试过修改glogin.sql,结果HP-DP的备份一直报错了,和HP的工程师检查了一周,后来还是我发现了这个问题,改了glogin.sql后,如果sqlplus nolog之后需要手工敲入一回车才能使用。

    Posted by: 小荷 at June 17, 2007 3:00 PM

    发表留言:



    Remember Me?
    (输入验证码后方可评论,谢谢支持)



    CopyRight © 2004 eygle.com, All rights reserved.