写完数据库迁移之后，我把文章链接发给一个朋友，他看完突然问我一个问题，迁移完之后的数据库怎么处理？或者没有迁移，因为业务系统下线从而数据库也跟着下线的时候，这些数据库该怎么办？
如同人活一世，一个数据库也会经历自己的出生到死亡。而如何给数据库一个葬礼，实际上却是很多公司没有好好做的。而我个人经历过的企业中，金融行业对这些要求更加严格一些，究竟如何给数据库一个葬礼，也是有诸多流程和讲究的。
第一步 死亡宣判
什么样的数据库可以被认定为是一个“死”了的数据库？这个事情不知各位DBA同行们可曾思考过。按照我过往的经验，在生产环境中，通常是以下几种情况：
- 业务调整后，数据库对应的业务系统正式停止使用
- 数据库已经完成向新环境的迁移，旧有的数据库不再被使用
- 因为灾备策略的调整，不再需要IT部门为某数据库提供灾备
- 公司某部门或业务被出售，相关数据库信息也要同时被买方带走
- 客户托管的业务发生托管协议的变更，即将不再被托管
其中1、2、3都是发生在自己公司内部，4和5涉及到多个公司实体之间的关系变化。前者相对容易处理一点，只需要公司内部流程确认；后者涉及到协议的具体内容，可能要双方同时确认方可生效。确认之后，也就意味着正式下达了数据库死亡的宣判。
第二步 排期执行
按照正常的流程，在宣判死亡之后，就要排期执行数据库的安乐死，通常是确定一个日期正式下线，这个日期通常是一周起步。这一过程有如下几个需要注意的地方：
- 先断开业务系统，在业务系统已经确认正式断开，并不会再有新业务的连入之后，不要立即停止数据库，而是禁用所有的非DBA的账号，关闭监控，观察是否有业务部门或者其他地方数据库访问受阻带来的反馈。在接到反馈之后，如果是业务部门的来源，直接将情况转给业务部门处理，如果是IT部门内部的访问，与内部同事进行沟通，告知该数据库即将下线。
- 对数据库做最后一次全备。这次备份将数据文件、配置文件、控制文件、日志文件等等所有数据库相关的内容都做一个完整的备份与恢复测试，并且做好长期保存的准备。根据不同行业的要求，做好数据归档，例如金融行业可能会保存20年，就需要以离线介质的方式留存，有的公司可能要求保存几个月，就可以选择放在备份服务器中。
- 正式关闭数据库实例，并继续静默一段时间，可以是一周或者更久，看公司的具体要求。因为总有可能出现某些冷门业务或者场景，突然又有了对数据库的访问请求但是有没有提前做好通知。甚至我还经历过已经停库超过2个月，某个业务部门来找，为什么他们季度取数取不到了。而当时数据库早就已经迁移到了新环境。
至此，整个数据库的的安乐死就算执行完成了，但是到这一步，仍然没有结束，因为还需要一个最后的葬礼。
第三步 举行葬礼
此时如果你是一个DBA，手头有一个已经关闭的数据库实例和一个完成最终备份且经过验证的备份集。接下来就要为这个服役过的数据库来一场最后的葬礼。
- 如果是需要与其他公司组织有数据交接的场景，此时需要对接方的相关人员做一个交接，根据协议内容，需要提交给对方哪些内容，有的时候是一个可以恢复的完整备份集加操作手册，有的时候可能是整台物理服务器。整个流程完成之后，双方签字确认走完所有商务与司法流程。
- 如果在交接完成后或者不存在交接，物理设备仍然还在你所在的公司，接下来就要按照公司流程和监管要求，对物理设备进行处理。如果这个设备要利旧继续使用，最好是对数据库所在的盘做全盘格式化，无法恢复原有的数据。如果服务器不再被使用，在走报废流程时做物理消磁。防止有人将数据恢复。
- 在内部ITIL与CMDB中，将对应的设备信息变更，将状态置为下线或同等意思的词语。此时的数据库，只剩下这样一个墓碑。注意的是，要把整个过程的时间点都记录清楚，以备不时之需，切忌含糊不清，任何有关生产环境的变更，都不是小事。
完成到这里，整个数据库的葬礼才算完成。在整个流程中，各类表单申请千万不要省，能详尽就详尽，确保每一步有迹可循，事后遇到纠纷时也可以拿出来佐证，不要为了省一时之便，为自己日后带来无穷的麻烦甚至丢掉工作，得不偿失。
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
