挑战
由于存在大量不兼容的特性，Oracle 到 TiDB 的迁移是一项耗时且成本较高的任务。在着手改造和迁移之前，应划定迁移范围，并估算迁移工期和成本。因此 Oracle 数据库与应用的信息收集尤为关键，而这需要多个团队协作完成。
解决方案
虽然 PingCAP 提供了 Oracle 数据库对象评估工具，但在一个成功的异构数据库迁移项目中，以下工作是必不可少的：
一、过滤掉明显不适合的场景
- 场景：TiDB 的适用场景主要集中在 OLTP 和实时 OLAP 领域。对于明显不适合的场景，比如传统数仓应用、大数据应用等，应避免使用 TiDB 来承载。
二、应用侧信息收集
- 存储过程与触发器：TiDB 不支持存储过程与触发器，所有存储过程都要改写为应用程序，触发器得触发方式也要改为应用接口触发。如果一个 Oracle 应用大量使用、且非常依赖存储过程或触发器，迁移成本将变得极高。
- 应用开发年份：越古老的应用越难迁移。用于从侧面判断迁移难度。
- 应用开发语言：是 Java 还是其他语言？使用哪种 ORM 框架？C、C++ 不是主流应用开发语言，相对而言，Java 语言是应用开发的首选，使用 MyBatis 或 Hibernate 框架是最流行的做法。用于从侧面判断迁移难度。
- 应用开发商：是否是当今活跃的开发商？用于从侧面判断迁移难度。
- 用到的 Oracle 特殊用法：如 UDF、树形查询、dblink、物化视图等。
- LOB 字段的使用：TiDB 支持的最大单个字段大小为 120MB，需要确认 Oracle 的 CLOB、BLOB 字段是否存在超过 120MB 的值。
- 批处理框架：TiDB 上运行批处理作业的最佳实践为小事务大并发，引入 Spring Cloud 等批处理框架可以充分发挥 TiDB 分布式集群的性能。
- 交易性能要求和现状：如，业务要求单笔交易响应时间低于 200ms，当前交易平均响应时间为 80ms。
- 容量预估及容量现状：如，未来三年的容量规划为 10TB, 当前 Oracle 库内容量为 2TB。
三、运维侧信息收集
- 交易性能现状：如，当前交易平均响应时间为 80ms。
- 容量预估及容量现状：如，当前 Oracle 库内容量为 2TB。
- Oracle 运行环境：收集当前 Oracle 运行的硬件平台、操作系统、存储类型等。
- 高可用和容灾要求：同城和异地的高可用与容灾要求（RPO、RTO 等）。
- 备份和恢复要求：备份和恢复效率要求，时间点恢复要求等。
- 归档要求：是否有数据过期归档策略。
- 安全类要求：安全、审计、加密、脱敏等要求。