挑战
从 Oracle 迁移到 TiDB 的主要流程为：Oracle 信息收集、分析与工作量评估，数据库对象改造与应用适配，数据迁移与生产切换。数据库对象改造与应用适配是整个迁移中工作量最大、成本最高的部分。对于某些年代久远的应用，往往只能借助应用更新换代的契机来进行数据库迁移替换。
解决方案
TiDB 兼容 MySQL 5.7 的语法与行为，部分不兼容特性，已经在官网文档中标出，Oracle 到 TiDB 的数据库对象改造应用适配中的大部分工作，可以参考 Oracle 到 MySQL 的方式进行迁移改造。
一、数据库对象改造
-
Schema 改造：PingCAP 提供 Oracle 表结构转换到 TiDB 表结构的自动化工具，该工具的字段转换规则总结于 PingCAP 过往实施的客户项目，用户也可以根据自己的需求对字段转换规则进行配置。需要注意的是，Schama 转换可能是有损的，需要去除 TiDB 不支持的特性，比如外键，比如有些超出 TiDB timestamp 类型最大精度的 Oracle timestamp 记录需要阶段后几位精度，等等。
-
物化视图改造：用实体表替代，数据处理逻辑和数据加载需要在数据库之外实现。
-
dblink 改造：用实体表代替，数据通过第三方 CDC 工具（如 DSG、OGG 等）加载。
二、应用改造
-
SQL 改造： SQL 改造往往是迁移工作量最大的部分，尤其是使用了抽象程度不高的开发框架，比如 Mybatis 等，需要把散落在各处的 SQL 都找到并改写。在功能测试时，也要尽量覆盖到完整的业务逻辑，避免改写出现遗漏。
-
Sequence 改造：TiDB 支持 Sequence 功能，其语法与 Oracle 略有差别。也可通过应用实现分布式序列号生成器。
-
Build-in Function & UDF：TiDB 不支持 UDF，另外 TiDB 和 Oracle 的 Build-in Function 并不完全兼容，对于不兼容的 Build-in Function 和 UDF，需要通过应用逻辑来实现。
-
CTE 与树形查询（Start with ... Connect by）：TiDB 支持 CTE，不支持树形查询，树形查询需要改写为 CTE（TiDB v5.2.0 最大支持 1000 次递归）。
-
参考 TiDB 数据库开发规范 针对 TiDB 的特点进行应用改造和性能优化。
三、迁移的契机
如前文所讲，由于成本的原因，我们很难通过数据库迁移来推动应用改造，更现实的策略是借助应用的换代升级来进行数据库迁移，应用的升级换代涵盖了应用语言更换、ORM 框架更换、应用功能加强、架构升级（如单机应用向分布式应用演进、微服务化、单元化改造）等。除此之外，TiDB 所不支持的特性（如外键、存储过程、触发器等）也需要在应用逻辑中实现。