Beginner
2007-04-20
DBA警世录:人祸猛于虎
传说中的故障,终于又见到有人遇到了。
今天在Thomas Zhang的杂货铺上看到这样一则故障:
存储厂商过来划分存储,不小心将已经在用的盘重新划分,导致2个应用测试库和一个培训库瘫痪。
万幸的是没把生产库也给搞掉[在一个阵列上]。
这真是一场千载难逢的灾难,也幸好还有万幸。
咋就有那么多不认真的工程师呢?存储厂商的工程师的操作也太草率了。
除此之外,我们不应该让存储厂商的工程师随意操作啊,DBA、SA的核查也是必不可少的。
记得我以前收录过一句话:
Don't believe a customer when they say they didn't do it. Get evidence.
我们也不应该相信任何第三方工程师,一定要自己确认後才能进行操作。
不过我接触的EMC工程师一般都比较慎重,不知道Tomas的存储是哪一家的?
收录于此,引以为戒!
-The End-
历史上的今天
- 2015-04-20 2015 DTCC: 后IOE时代 Oracle将何去何从?
- 2013-04-20 2013 DTCC数据库大会演讲记 - CBO与成本计算
- 2011-04-20 Max Extents越界导致故障的Oracle数据库恢复
- 2009-04-20 Oracle 74亿美元购SUN - 彻底改变产业格局
- 2006-04-20 使用10203事件跟踪Oracle块清除
- 2005-04-20 五一出行计划
DELL工程师曾经在为做任何通知的情况下重启一个客户的CX500,可怜上面挂的几台数据库啊。。。。。
等待Thomas出来揭晓这个伟大的厂家
和前不久美国政府的那个差不多啊, 人家花了2M美刀的成本重新输入数据啊。
这都能说什么列?
所以我的现场,一般都不让别人动,os密码和db密码都在我这
我兼dba/sa
反正不管如何,出事都是我抗
这都能说什么列?
所以我的现场,一般都不让别人动,os密码和db密码都在我这
我兼dba/sa
反正不管如何,出事都是我抗