偷偷分享下干了15年乙方，维保40+国企的Oracle迁移升级心得...

目前大多数客户面临硬件老化，存储性能不能满足目前业务的需求，低版本bug触发几率大，性能不稳定，故障频发，运维人员缺少，AI 时代的多模等技术变革，急需低版本升级到19C或者更高！

接下来就给大家分享一下升级迁移的一些心得...

1.迁移方案

我们常常需要对数据进行迁移，迁移到更性能配置更高级的主机OS上、迁移到远程的机房、迁移到不同的平台下，常见的迁移方案如下：

2.迁移方案对比分析

经过多年的经验积累，行业中以10TB级的数据库为例，常规的迁移方案对比如下

3.迁移应该考虑哪些？

如何选择合适的升级方法与路径?
见并有效规避?如何保证平滑升级?升级过程有哪些风险?
如何做到全部可预统、网络等有什么要求?新特性如何使用?
操作系如何保障?用户体验是否下降?
升级后应用系统性能应用代码是否需要改造，工作量有多大?
数据库本身升级对数据安全性、运行稳定性是否有影响?
升级停机时间，升级不成功能否回退，有无应急方案?
升级后备份方案调整、监控运维的变化调？

4.业务数据梳理

前期准备是数据库升级项目成功保证，业务数据梳理，保障迁移顺利！

1.数据库对象
确认同步的数据库表·查看使用的序列·物化视图 
2.表属性分析
表的大小、数量是否存在nologging·是否存在压缩属性
3.数据类型分析
确定数据类型分布·不支持的数据类型
确认应用存在限制的数据类型·LOB字段
4.特殊表
检查是否存在外部表检查是否存在临时表
含LOB字段的大表
5.日志量  Redo log Volume
平均日志量(GB/分钟)· 峰值日志量(GB/分钟)
6.特别注意
没有主键的表、触发器、存储过程、定时job

5.参数调整

系统上线前，Oracle数据库参数的调整至关重要，行业经验总结的参数调整，能帮助你避坑

6.迁移后监控和优化

数据同步优化，监控和优化同步通道，建议大家使用EMCC平台

Oracle EMCC（全称Oracle Enterprise Manager Cloud Control），是Oracle公司推出的一套集中化综 合性管理平台，可以针对数据库、主机操作系统、中间件、企业级应用程序进行管理的自动化管理，特别是在管理 Oracle数据库方面功能非常全面。

7.案例分享

7.1 零停机OGG迁移案例

GoldenGate:实时、跨异构和支持交易、事务完整性的复制,此迁移方式在不影响原生产库的情况下实现在线迁移，OGG 迁移核心思想：前期部署好源端 OGG，然后利用数据泵导入导出所需业务初始化数据，然后目标端部署 OGG 基于 SCN 启动通过 OGG 同步增量数据。

本案例实现了客户提出的30分钟内的HPUNIX到一体机ODA的平滑迁移

7.2 Autoupgrade升级案例

本案例是将一套12.2.0.1的RAC集群升级到19.16.0.0的RAC集群，采用的升级方式是先通过Dataguard+failover方式将数据库实时复制到异机的新环境RAC集群，并在异机的新环境上通过Autoupgrade的方式将数据库升级为19.16.0.0

7.3 XTTS迁移案例

如果你的数据量很大，迁移停机教短吗，那么就要选择XTTS了，通过XTTS快捷、高效、平稳、安全的将Oracle数据库“小型机+集中式存储”环境迁移至“X86架构平台+分布式存储”已然成为一大神技!

总结

数据库升级迁移，是一项涉及面广、复杂繁琐的工作，可以带来很大的收益，但同样面临很多的问题及风险。