数据库版本管理是很多大的企业和机构比较头疼的问题，通常来说，他们对版本管理有以下的期望：
希望数据库版本尽可能少，使得运维的场景尽可能单一
相同版本的数据库尽量维持在某一个补丁集上
解决了某一套系统的Bug或异常后，希望将这个经验也应用到其他系统
理想很丰满，但是现实却很骨感，由于数据库的套数很多，要实现上述的目标并不容易。
首先，不同的业务系统上线的时间不一样，对应到当时的数据库版本和补丁集不一样；
其次，已投产的系统做变更，需要一系列的测试流程，维持现网数据库版本统一代价巨大。
近期我们在帮助众多客户梳理补丁策略时，总结出一套相对合理的方案，帮助客户在落地成本和稳定性、技术先进性上保持一个相对较好的平衡。
这个方案的整体的目标是企业中所有的数据库都统一到一个大版本上，比如Oracle 19C是官方推荐的长生命周期版本，建议都统一到这个版本上。
实现的路径如下：
选择试点业务，积累技术经验
根据业务系统的重要程度，将数据库划分为几个象限，不同的象限采用不同的策略。重要程度较低的系统数据库，采取相对激进的策略，选择相对较新的技术。比如CDB是Oracle数据库未来的架构方向，它的设计理念和技术路线和传统模式都有较大的不同，因此系统整体架构的规划和运维场景都和以往有所不同，那么可以先在一些边缘系统使用这种架构，为将来核心系统改造积累足够的经验；
RU + Oneoff 是稳定的基础
每个新版本的数据库都会有不同程度的问题，但软件厂商的生命周期策略使得用户不得不跟着升级。因为没有足够的积累，新版本的引入给系统的稳定性带来较大的挑战。因此建议通过1-2年的时间，磨合一个相对稳定的 RU + Oneoff 补丁组合，比如19.10，之上打了50多个 Oneoff，形成一套相对稳定的版本基线；
确定基线版本后大面积推广
在这个基线版本的基础上进行大面积的推广，其他所有的系统都向这个基线版本靠齐。由于数据库本身的稳定性已经得到验证，因此这个阶段不再需要大量的数据库稳定性测试，仅需要业务进行有针对性的兼容性测试；
Bug修复看整体的影响
在个别系统故障，涉及到需要调整参数和应用补丁进行修复的，主要看影响面，影响大、发生面积大的会吸纳到版本基线中，影响小的则个别系统单独处理。
使用Oracle RHP实现版本统一管理
Rapid Home Provisioning (RHP) 是Oracle 12C中推出的一个新的组件，帮助企业以标准化、统一化的方式，在软件基础设施的所有体系结构层上进行部署、补丁、升级等工作。具有变更时间短，版本回退操作简单等优点，大大降低大批量数据库版本的统一管理的成本。
