最近碰到一件事情很感慨，简单说说。
有下面的三个数据库实例，都是在开发测试中使用，一台服务器上有业务1+业务2，另外一台服务器上有业务1+业务2.
当然为什么会有这种重合，对于DBA来说也实在无从得知。
从数据整合的角度来看，服务器1上的业务2数据库目前的负载很低，而且和业务1的交互比较多，本来拆分的库现在要考虑整合起来，也真是应了那句话，分久必合，合久必分。
业务1，业务2独立存在数据库服务器我们称为服务器1，业务1+业务2整合在一起的服务器我们称为服务器2.
现在从技术的角度来看，整合有几种思路，一种是把业务1+业务2的整合在一起，然后考虑把另外一台服务器的业务1+业务2整合起来。
另外一种思路就是业务1+业务2整合起来，业务1+业务2的服务器还是跑目前的开发测试任务。
虽然开发测试库对于数据要求没有那么高，但是出了问题还是很影响进度的，所以目前的情况就是先抛弃了逻辑异机备份，直接搭了dataguard环境，这三个实例的备库都放在了一个服务器上，我们称为服务器3
这个时候数据的整合就好像控制数据流动的开关一样。业务1，业务2的业务目前是独立，但是交互较多，业务2的负载很低，所以考虑业务1和业务2整合在一起，当然用户还是彼此独立。
其实这个时候这种迁移的代价还是很低的，防火墙信息不需要改动，数据库服务端的网络配置也不需要改动，用户名密码都不变。数据不变。唯一需要修改的就是应用端的SID需要调整为业务1对应的SID
那么我们就开始做详细的准备和分析，最后锁定了几个用户，然后准备了相关的脚本，迁移的步骤，迁移的时长评估等等。甚至考虑线上的业务整合如果有演练需 要，可以考虑在snapshot standby上完整模拟等等。一切都准备的有条不紊。然后准备就绪之后，就准备和开发的同学商量一下，让他们协调配合做这些改动，确认之后我们就可以开 始干活了。
对于服务器2，目前也比较纠结，但是目前的情况是和服务器1整合起来，难度还是比较大。而且数据量也有不少，至于为什么业务重合度这么高，DBA同学也没搞明白。我是完全从数据迁移的技术角度全面评估的。发现基本的思路和解决方案目前来看都是可行的。预期的整合效果如下：
然后和开发的同学简单沟通了一下，就等待他们的回复了。脚本已经准备的妥妥的了。然后过了一会开发的找到我，我们私聊了一会，根据他们的反馈，目前服务器1上的两个数据库现在都已经不在使用了。也就意味着迁移压根就没什么搞头。
当然我也确认了一下服务器1上的连接情况，发现都是数据库内部的进程连接。
所以我几乎没有做什么工作就顺利完成了业务整合和迁移。
对于这个小案例，其实我也是感概良多，很多时候工作要紧密结合业务使用，没有业务使用的支持，技术方案再好，再全面也会没有用武之地。如果提前和开发同学 沟通，提前了解一下具体的业务使用情况，这种无用功的情况就会大大减少，这从某种程度上也需要彼此的配合和支持，很多时候工作中大家都害怕给自己惹麻烦， 还是出了问题都规避不了。
