每逢假期,我们总会接收到很多数据库故障救急请求,因此我甚至经常发出以前的一个总结:警惕数据库假期综合症,呼吁大家提高警惕,防范疏忽下发生的故障和问题。
在这个元旦假期中,我们同样收到了很多的紧急援助请求,这其中大多是熟悉的问题,包括:
阳光之下,并无新事,这些问题大都是我们以前曾经面对过的,很多专家已经写过了很多案例,如果大家对类似的问题感兴趣,我甚至总结了一个页面,供大家参考:
http://www.eygle.com/blog/special/oracle_recovery.html
然而我想重复的,DBA至关重要的一项素质是:严谨。在面对重要操作时的小心谨慎,反复确认;在可能损坏数据操作时心怀警惕,确认无误;唯有充分重视这份数据工作,才能在实践中履险如夷,达成使命。
比如误删除操作这样的事故,直至今天,在很多用户环境中仍然屡见不鲜。
上周在微信大讲堂中还有人提问:是否可以用update user$的方式更改Oracle数据中的用户名?
以上提及的问题,一步走错,就可能为生产数据库带来灾难,企业一方面我们可以通过加强规范来防范错误,一方面可以通过技术手段去防止问题(比如在一定程度上禁用DDL),而DBA们在进行一个操作之前,一定要足够严谨,把握住最关键的执行一环。
在2016年,我们祝愿所有的DBA们能够更加严谨顺利,更上一层楼。
这次用户误删除的案例,让我想起多年以前论坛上的一则误删除案例,与大家分享共为警醒:
最惨的一次(经历)是和公司的一个哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反了一下,但是tnsnames没做修改,我准备重做备服的时候,使用了drop user cascade,把所有的用户都干了一遍。 刚刚干完,所有科室上夜班的护士小妹妹都给我打电话,说科室里的电脑全部不能用了,当时急的不行了,还好习惯还不错,来的前一天做了一个全库冷备,立刻进行了恢复,不过也丢失了一整天的数据。 一个小时以后,所有的院领导以及信息科的工作人员都出现在我的面前,并质问我原因,我只能一脸无奈的告诉他们刚刚来了只熊猫,那只熊猫烧了把香,然后数据就全丢了。 然后给了他们一个卖瑞星的兄弟的电话,那个兄弟连夜驱车200公里赶到目的地,到场以后首先确实了一下那个烧香的熊猫的存在,然后指出了那只熊猫的巨大危害性,最后建议他们购买一套全院级的杀毒软件。 大院长听取汇报后当即指示,立刻购买一套全院级的杀毒软件,第二天一早就在购买合同上签字盖章。 这个事情造成四个后果, 第一,我在所有删除性操作以前都要核实一下对象的准确性, 第二,我从此拒绝和那个哥们一起出差, 第三,那个卖杀毒软件的兄弟会经常联系我,看看我有没有犯类似的错误。 第四,兄弟越多越好
富有戏剧性效果的案例,说出一个心酸的真实故事,但愿我们都不要通过跌倒去收获经验,而是通过严谨去防止错误吧。
近期文章
从Approx_Count_Distinct到M7的CPU集成
Cloud时代DBA的DevOps最佳实践 - SQL 审核
云和恩墨
数据驱动,成就未来。整合业界顶尖的技术与合作伙伴资源,围绕数据及相关领域,提供解决方案和专业服务。
业务架构
电子渠道(网络销售)分析系统、数据治理
IT基础架构
分布式存储解决方案
数据架构
Oracle DB2 MySQL NoSQL
专项服务:架构/安全/容灾/优化/整合/升级/迁移
运维服务:运维服务 代维服务
人才培养:个人认证 企业内训
软件产品:SQL审核、监控、数据恢复
应用架构
应用软件开发管控:数据建模 | SQL审核和优化