DBA致命的低级工作？超大型系统数据库版本质量控制( 二 ) _DBA

二、实施阶段
实施阶段，这指版本实施的窗口时间段。
1、生效方式和流程
如果你要创建三张表，你有可能会写三个脚本依次运行，也有可能会写一个包含创建三张表的脚本一次性运行。这看起来好像没什么区别。但是在大型版本的情况下，是完全不一样的。我们先简单的增加一下工作量，假设我们一个稍微复杂一点的数据库表变更表中字段，我们大约需要以下几个步骤：

数据导出
数据加工
数据库表删除
数据库表重建、索引重建
数据加载

只要同时操作20张数据库表，就有100个小步骤。如果每一个小步骤需要执行一个脚本，那么投产切换的步骤就需要执行100个脚本。这时候DBA基本上就不太可能选择自己去手工运行这100个脚本了。那用一个脚本运行这100个DDL行不行？大概率也是不行的，因为在7*24的系统上，你可能要在有限的时间窗口里，完成大量的步骤，这大概率需要更合理的流程。
比如说数据库表的导出、不同数据库表的数据加工等操作可以同步并行执行。这时候，就需要考虑不同步骤之间的依赖关系。随着多种变更方式混合在一起，可能有的项目新建表，有的是加索引等等，超大型的版本流程会变得复杂起来，而且不易于人类来记忆。这时候，DBA需要设计一个流程调度者，它可能是某个程序进程，来有条不紊的控制整体版本流程的高效生效。
2、异常报错处置
即使在拥有一个完美的生效流程的前提下，也无法保证版本实施生效过程中，绝对不报错。比如说，你的用户缺少某个权限、数据加工中磁盘空间不足等等。这时候你设计的调度程序，需要能够准确的识别异常，并可以隔离掉与这个步骤有关联的步骤，同时保证与之无关的步骤还能继续执行。
此外，在问题解决之后，异常相关的步骤还需要比较简单的重新唤起机制。整个异常处理的过程，需要清晰的日志痕迹，方便快速的错误定位和事后复盘。
3、检核机制
即使你建了100张表的超大流程完美运行，没有任何报错。你会不会产生一种怀疑，“我有没有可能漏跑一个索引？”难不成执行完之后，去一个个DESC表来检查运行结果？显然不可能。所以超大型的数据库版本一定会要配备生效后的检核机制，它可能是针对数据或者是元数据的。
三、进阶问题
除了这些之外，既然你是一个超大型系统的DBA，你所面对的肯定不仅仅是如此，当然接下面这些问题的本质与上面的问题还是一致的。
1、版本叠加
一个超大型系统，在一些公共或者平台能力的数据库表的修改上会有版本叠加的可能性，比如说程序员M，因为某个需求在某个表A上增加了字段COL1 。同时程序员N，因为另一个需求在表A上增加了字段COL2 。他们有可能在同一天，或者是前后差几天的时间里面上线。M和N甚至可能在不同的环境开发和测试，他们有可能互相不知道对方需求的存在。
这时候，DBA需要在很早的时候，甚至是他们开发的早期，就具有识别版本可能叠加风险的能力。而不同项目组，使用了不同的测试环境，DBA还需要确保上线的数据库版本，在多个不同测试数据库版本同时存在时，依旧准确无误。
2、量级性异常
系统一大了，奇怪的错误也更容易出现。因为很多时候，往往由于成本原因，超大型系统往往难以配备和生产环境一模一样的硬件设备。减少测试环境的数据量，是非常常见的作法。那么测试环境的数据量远少于生产环境时，就经常会因此出现问题。比如磁盘空间不足、磁盘吞吐能力瓶颈、执行计划差异等等。还有可能是大规模的数据清理或者操作，引起诸如REDO 空间不足，BINLOG同步炸掉之类的问题。
四、我们怎么应对
几乎每一个程序员，都会写一些自己常用的工具代码来简化自己的日常工作。当然也包括DBA 。这样做的好处是显而易见的，我们看看可以通过一些工具程序来做些什么：
工具程序会根据开发者的使用数据结构（或者企业级元数据字典），直接产生DDL，这可以非常有效的避免手滑问题。最重要的是，产生一个DDL文件和产生一万个DDL文件，对于代码来说，不仅仅花费时间几乎是一样，出现问题的概率几乎是一样的。
工具程序在数据库评审的时候，就会根据项目录入非常具体的设计信息和范围，包括涉及的表、索引有哪些，SQL语句有哪些。并且在每一次设计调整时，我们都可以通过工具生效在测试环境之后，留下变化的记录。那么，在某个投产日的项目范围确定之后，整个系统的数据库变更范围随之确定。这样不容易上错内容，也不容易缺少什么内容。