每逢假期，我们总会接收到很多数据库故障救急请求，因此我甚至经常发出以前的一个总结：警惕数据库假期综合症，呼吁大家提高警惕，防范疏忽下发生的故障和问题。
在这个元旦假期中，我们同样收到了很多的紧急援助请求，这其中大多是熟悉的问题，包括：
数据库回滚段问题导致的ORA-01555错误；
SYSTEM表空间坏块导致的BootStrap失败，2662错误；
误删除导致的数据丢失；
空间不足导致的归档挂起；
阳光之下，并无新事，这些问题大都是我们以前曾经面对过的，很多专家已经写过了很多案例，如果大家对类似的问题感兴趣，我甚至总结了一个页面，供大家参考：
http://www.eygle.com/blog/special/oracle_recovery.html
然而我想重复的，DBA至关重要的一项素质是：严谨。在面对重要操作时的小心谨慎，反复确认；在可能损坏数据操作时心怀警惕，确认无误；唯有充分重视这份数据工作，才能在实践中履险如夷，达成使命。
比如误删除操作这样的事故，直至今天，在很多用户环境中仍然屡见不鲜。
上周在微信大讲堂中还有人提问：是否可以用update user$的方式更改Oracle数据中的用户名？
以上提及的问题，一步走错，就可能为生产数据库带来灾难，企业一方面我们可以通过加强规范来防范错误，一方面可以通过技术手段去防止问题（比如在一定程度上禁用DDL），而DBA们在进行一个操作之前，一定要足够严谨，把握住最关键的执行一环。
在2016年，我们祝愿所有的DBA们能够更加严谨顺利，更上一层楼。
这次用户误删除的案例，让我想起多年以前论坛上的一则误删除案例，与大家分享共为警醒：
最惨的一次（经历）是和公司的一个哥们一起出差,那个哥们不知道出于什么考虑,将主服务器和备份服务器的IP反了一下,但是tnsnames没做修改,我准备重做备服的时候,使用了drop user cascade,把所有的用户都干了一遍。
刚刚干完,所有科室上夜班的护士小妹妹都给我打电话,说科室里的电脑全部不能用了,当时急的不行了,还好习惯还不错,来的前一天做了一个全库冷备，立刻进行了恢复,不过也丢失了一整天的数据。
一个小时以后，所有的院领导以及信息科的工作人员都出现在我的面前，并质问我原因,我只能一脸无奈的告诉他们刚刚来了只熊猫，那只熊猫烧了把香,然后数据就全丢了。
然后给了他们一个卖瑞星的兄弟的电话,那个兄弟连夜驱车200公里赶到目的地,到场以后首先确实了一下那个烧香的熊猫的存在,然后指出了那只熊猫的巨大危害性，最后建议他们购买一套全院级的杀毒软件。
大院长听取汇报后当即指示，立刻购买一套全院级的杀毒软件，第二天一早就在购买合同上签字盖章。
这个事情造成四个后果,
第一,我在所有删除性操作以前都要核实一下对象的准确性,
第二,我从此拒绝和那个哥们一起出差，
第三,那个卖杀毒软件的兄弟会经常联系我，看看我有没有犯类似的错误。
第四,兄弟越多越好
富有戏剧性效果的案例，说出一个心酸的真实故事，但愿我们都不要通过跌倒去收获经验，而是通过严谨去防止错误吧。
文章转自数据和云公众号，原文链接
