谋定而后动,常怀敬畏之心--生产库DBA必备素质
这两天遇到一个抓狂的事情，上来给大家抱怨下，也算是给刚入行的兄弟一点提醒：
大概两天前我收到一个电话，一个从未谋面的兄弟告诉我他现在接管n年前我曾经管理过的一个某数据仓库的生产数据库，但是觉得有一些地方设计的非常不合理，想修改下，打算和我探讨下可行性。
当时我的回复是，这个数据库我n年不碰了，细节的东西基本都不记得了，但是需要注意的是，这样一个运行了几年的数据仓库，所有存在的东西都是合理的，有些设计可能从局部看是低效，甚至于愚蠢的，但是大多有着一定的历史背景和设计原因。除非150%必要，请不要轻易去做调整，如果真的是非改不可，也请一定搞清楚当时做的时候的历史背景，设计思路。很多东西在局部看可能是愚蠢的，但是放到全局看，也许是相当合理的。况且你刚接手这个库，不建议做任何设计上的调整。
当时这个兄弟‘哼哼’了两下，不置可否。 因为这个还是我上一家公司的项目，和我也没任何关系了，况且对方的态度也基本是不配合，估计来咨询我的意见也是受上级领导的指示，并非是其本意，我也就没继续多说什么了，觉得尽到必要的告知义务就可以了。
谁知道昨天又接到他的电话，说他手工修改了一些存储过程，然后维护了一张基础表，但是操作的时候感觉出了点问题，执行的时间很长，一张几十万记录的表跑了几个小时。然后第二天早上发现很多报表里的数据都丢掉了。问我改怎么办。
我问了下具体的操作步骤，他是直接在仓库里面敲sql来修改数据的，而且sql本身是很复杂的，涉及到好几张表的join。 真是相当生猛啊，居然在生产库里直接敲sql然后都不先测试下，而且执行时间超长也没觉得紧张。 我后来又问了下报表数据丢失的情况，基本可以判断是一张非常重要的基表数据混乱了，ETL过后，整个报表层的数据基本都错乱了。修复的话，估计相关数据都要重新装载下，涉及到的所有中间表和报表数据都是要重新装载了。公司的相关人员基本要全部出动了， 停机一个星期能够重新装载成功就要谢天谢地了，公司的高层估计都不能幸免，也要出面给客户来解释这个问题了。基本上又是一起由于DBA手痒引起的悲惨事件。
给大家讲这个案例，主要是提醒一些刚入行的小兄弟，生产库的维护技术上可能不是特别的要求高，但是心态上勿必慎之又慎，任何操作都必须怀有敬畏之心，充分理解你这条命令所带来的后果以后才能执行，谋定而后动。另外对于一些历史悠久的数据库，所有存在的都是合理的，当初的设计也不是找了头猪来做的，千万别觉得自己比当初设计人员高明，尤其是在你充分理解了整个系统以前。
