2. 迁移需求与现状调研

迁移项目最容易失败的地方，不是切换当晚的操作，而是调研阶段漏掉了一个系统、一个补丁、一条依赖或一段停机约束。需求与现状调研的目标，是把“要迁什么、迁到哪里、能停多久、必须满足什么”变成一份可核对、可量化、可追溯的基线。它既是迁移方案设计的输入，也是后续割接回退判断的依据。

一、业务系统清单：先划清迁移边界

调研第一步不是打开数据库，而是先建立业务系统清单。清单要回答三个问题：哪些系统使用这套 Oracle、它们之间是否有调用关系、哪些系统本次必须一起迁。建议按“业务域—系统—数据库实例—连接方式”四级展开，字段至少包括：系统名称、业务负责人、技术负责人、数据库实例名、连接串/服务名、连接账号类型（应用账号、报表账号、批处理账号）、日均交易量、是否有对外接口。

实际调研中，常见的情况是同一个实例被多个系统共用。例如某订单库同时被订单中心、结算平台、BI 报表三套系统连接。如果只按“数据库”登记，割接时容易漏掉报表系统，导致切换后报表连接失败。因此清单必须落到“系统—实例—账号”的粒度，并标注每个连接是否允许在停机窗口内中断。

二、数据库版本与补丁：决定迁移路径

版本与补丁直接决定可用工具和迁移方式。需要采集：数据库版本（如 11.2.0.4、12.2.0.1、19c）、补丁集（PSU/RU 版本号）、是否启用多租户（CDB/PDB）、字符集（如 AL32UTF8、ZHS16GBK）、归档模式、RAC 或单实例、Data Guard 配置。这些信息决定了能否使用 Data Pump、可传输表空间、GoldenGate 或 Data Guard 切换。

例如源库为 11.2.0.4 单实例、非 CDB、字符集 ZHS16GBK，目标为 19c CDB 中的 PDB、字符集 AL32UTF8，则不能直接做可传输表空间，需要评估 Data Pump 加字符集转换，或先升级再迁移。补丁差异还会影响导出工具兼容性，源库补丁过低时，Data Pump 导出文件可能无法被目标库直接导入。

三、数据量、对象类型与依赖关系

数据量不能只看“总大小”，要拆成：数据文件总容量、实际使用量、最大单表、最大分区表、LOB 数据量、索引大小、每日增量。对象类型要统计表、分区表、索引、物化视图、序列、同义词、存储过程、触发器、定时任务（DBMS_SCHEDULER/JOB）、外部表、数据库链接（DBLINK）。

依赖关系是调研中最容易被低估的部分。数据库内部有对象依赖（视图依赖表、过程依赖表、触发器依赖表），数据库外部有系统依赖（DBLINK 指向其他库、应用通过 TNS 连接、ETL 任务依赖特定账号）。建议用数据字典查询辅助梳理：

-- 统计各对象类型数量
SELECT object_type, COUNT(*) FROM dba_objects
WHERE owner NOT IN ('SYS','SYSTEM','DBSNMP')
GROUP BY object_type ORDER BY 2 DESC;

-- 查看失效对象
SELECT owner, object_name, object_type, status
FROM dba_objects WHERE status = 'INVALID';

-- 查看数据库链接
SELECT owner, db_link, host FROM dba_db_links;

-- 查看定时任务
SELECT owner, job_name, enabled, repeat_interval
FROM dba_scheduler_jobs;

这些查询结果应直接进入调研表。失效对象、指向外部库的 DBLINK、启用的定时任务，都是割接时必须单独处理的项。

四、停机窗口与合规要求

停机窗口要区分“可接受停机时长”和“实际可用切换时长”。前者由业务方给出，后者要扣除准备、验证、回退预留时间。例如业务允许停 4 小时，则实际切换操作应控制在 2.5 小时内，留 1 小时验证、0.5 小时回退决策。窗口类型也要标注：是周末夜间、月末结算后，还是只能利用业务低峰做在线迁移。

合规要求包括：数据是否允许出生产机房、是否要求加密传输、是否涉及个人敏感信息、审计日志是否必须保留、是否要求迁移过程可追溯。这些约束会直接影响迁移工具选择和中间文件存放位置。

五、把调研结果落成可执行基线

调研完成后，应形成一份“迁移现状基线表”，作为方案评审和割接检查的共同依据。下面给出一份可直接参考的字段示例（数据为教学示例，非真实实测）：

调研的最终判断标准是：任何一个迁移动作，都能在基线表中找到对应的输入项；任何一个割接异常，都能在基线表中找到对应的回退依据。做到这一点，后续的方案设计、演练和正式割接才有稳定的起点。