去ORACLE 喊了多少年了，已经是50岁的大姑娘出嫁，不新鲜了，但是去ORACLE 这个话题的操作性仅仅是围绕那个数据库去更换ORACLE，很少听到，到底怎么从企业实际的业务角度来去除ORALE 数据库。恰巧最近新入驻的企业要彻彻底底的，去除ORACLE，这里就把正在做的事情来说说。
1 去ORACLE 难题有哪些
去除ORACLE 数据库本身并不是难题，难题是基于ORACLE 特性以及ORACLE 以上的应用怎么操作的问题
难点1： 所有的业务都在一个ORACLE 数据库上，这的确是一个难点，很多使用ORACLE的作为业务数据库的应用都有一个特点，除非是“良心” 发现，将不同的业务装配到不同的ORACLE 实例上，否则一个ORACLE 数据库被装载多个业务的表是常见的问题。
对这个问题类型的ORACLE ，实际上使用哪个数据库去更换并不是那么重要，从业务的角度去先将业务从数据库中拆分是重要的，不同的业务一组表，将这组表迁移到其他的数据库实例上，算是这类状态下，去O的日常工作
总结：这类问题，在于早期业务使用数据库方式的问题，后续从不同的业务中将表根据业务功能进行分组，是这种类型去ORACLE 的第一步工作。
难点 2： 数据的处理方式的问题，在ORACLE 中部分数据处理的方式有使用存储过程，或函数以及TRIGGER , 物化视图，等方式，数据处理的方式是去ORACLE 第二个难点，首先有一些是ORACLE 独有或特有的处理数据的方式，在承接的数据库中是否能完成这个功能，如分布式数据库大部分不支持存储过程，支持存储过程的性能也不会好很多，物化视图更是这样，大部分数据库都没有物化视图的功能，或者FLASH BACK的功能，以及非常聪明的SQL 处理解析的方式，所以选择承接的数据库方面也需要花心思来选择。
难点 3：数据量以及单表承载数据的问题，这点上虽然比上面的问题要简单，但是和上面的两个问题牵连，大型ORACLE 系统的数据在放到其他数据库上时，部分概率会牵扯到分表，将原来的一个表的数据拆分到多个数据表中，业务逻辑方面也是需要注意的。
基于上面的三点考虑可以总结出一个分类图
首先确认的问题
1 ORACLE 在迁移时必须对业务要进行梳理，妄想数据库平移，业务系统不做调整的，那基本上是在痴人说梦，所以去O 必然是一个系统重构部分的过程，同时这里在系统重新梳理和操作的过程中，应用系统可能还要设计出产出两种数据库操作语句的系统，比如在进行去O 的项目过程中，对关键业务进行逐步的迁移，应用系统能兼容 ORACLE 和另一种数据库产品的语法。
2 数据量评估，在去O的过程中对于固有数据，存留数据要有评估，同时对增量数据也要有评估。这对选择替换ORACLE的数据库的类型和方式有一定的意义。
比如ORACLE 中存储的数据都是日志类的数据，那么大可以放到MONGODB 中处理，并且通过自动清理的方式来管理这堆日志数据，或者单体表过大，通过业务不可以进行分割的，那么通过PG 来存储这样的大表并进行数据的写入和查询的操作，还有在业务可行的基础上，进行分库，分表的操作，通过MYSQL 来处理溢出的数据。但前提是，需要获知自己的应用产出的数据，和数据量。
3 数据导入导出，数据同步的方式，这点是需要考虑的，比如ORACLE TO MYSQL，ORACLE TO PG , ORACLE TO MONGODB ，这些数据库是否可以和ORACLE 进行数据的实时同步，或者如何一次性快速的导出数据，同时也不能将一切问题都压在数据库的头上，在业务端程序端，架构端，可以采用早期非切换时期的历史数据迁移，以及切换业务后的，增量数据拷贝后切换，等，所以理解业务在数据库中做了什么还是很重要的，比如对历史数据经常UPDATE 的操作，可能就不适合上面的方式，可能需要一个时间点来进行统一的切换，或通过cannal ,otter 等工具进行辅助的数据同步。
基于上面的问题总结
1 更换ORACLE 的数据库选型
2 业务数据持续同步的方式
3 基于业务的灵活性提供切换数据库的方法
4 异构数据库数据的导入导出问题
5 整体应用数据库切换不同语句撰写的方式方法
6 数据存量和增量的估算，对选型数据库数据计算和数据承受力的评估
7 ORACLE 的原有的功能，在其他数据库上的实现或应用程序，或非数据库中间件的支持和改造
综上所述，去除ORACLE 不是一个分布式数据库，或者MYSQL ，或者整体迁移所能一步到位的，原先在ORACLE 上的应用管理的越混乱，基于ORACLE 原有的功能越依赖，则去除ORACLE 的困难越大。
基于去ORACLE的工作，是一个基于架构，开发，数据库，业务等多方面的工作，需要各方努力，才能将ORACLE 从数据库的 SUPPORT LIST 上抹除。
