3. 业务平台现状评估

迁移到 Oracle Cloud 之前,最容易被低估的工作不是“怎么迁”,而是“迁什么、迁得动吗、迁完能不能达标”。现状评估的目标,是把散落在各处的数据库事实收敛成一份可量化、可追溯的迁移就绪度评估报告。它至少要回答四个问题:资产有多少、版本与特性是否受支持、依赖关系会不会成为阻断点、性能与合规能否在目标端复现。

一、资产盘点:从“清单”到“可迁移单元”

资产盘点不能只统计实例数量。一个可迁移单元通常由实例、数据库、Schema、数据量、字符集、归档模式、连接入口共同定义。建议从 Oracle 数据字典与监听状态入手,先取实例级事实:

-- 实例与版本基线
SELECT name, db_unique_name, open_mode, database_role,
       version, version_full, platform_name, cdb
FROM   v$database;

-- 数据量与表空间占用
SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS gb
FROM   dba_data_files GROUP BY tablespace_name ORDER BY 2 DESC;

-- 字符集与归档
SELECT parameter, value FROM nls_database_parameters
WHERE  parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');
SELECT log_mode, force_logging FROM v$database;

示例:某业务平台盘点出 6 个实例,其中 2 个为 11.2.0.4 单实例、3 个为 12.1.0.2 RAC、1 个为 19c 多租户。总数据量约 4.8 TB,最大单库 2.1 TB,字符集为 AL32UTF8,归档模式已开启但未强制日志。这些事实直接决定后续选型:11g 需先升级或采用逻辑迁移,19c 多租户可优先考虑 PDB 级搬迁。

二、版本与特性:识别“不支持”和“需改造”

版本评估要区分三类:目标端完全支持、需要升级后支持、必须改造。Oracle Cloud 上可用的数据库服务版本以 19c 和 23ai 为主,11g 已不在主流支持范围。除版本号外,更要关注依赖特性:DBLink、外部表、Java 存储过程、Advanced Queuing、物化视图刷新、调度作业、目录对象、加密钱包。这些对象在迁移后往往需要重新配置或替换。

判断口径建议统一:凡目标端不支持的语法或组件,标记为“阻断”;凡支持但需重新配置的,标记为“改造”;凡可直接搬迁的,标记为“就绪”。

三、依赖关系:画出真正的迁移边界

依赖关系是就绪度评估中最容易漏掉的部分。数据库之间通过 DBLink 互访、应用通过 TNS 别名连接、ETL 通过外部表读取文件、报表通过物化视图取数,这些都会形成隐式耦合。评估时应至少梳理:库间 DBLink 指向、跨库同义词、共享目录对象、外部表数据源、以及应用连接串中的主机名与端口。

-- 库间依赖
SELECT owner, db_link, host FROM dba_db_links;
SELECT owner, synonym_name, table_owner, table_name
FROM   dba_synonyms WHERE table_owner IS NOT NULL;

示例:盘点发现 3 条 DBLink 指向已下线的报表库,2 个外部表指向本地文件系统路径。前者可直接清理,后者需改为对象存储或 OCI 文件存储路径。依赖关系图的价值在于:它决定了迁移批次和割接顺序,而不是简单罗列对象。

四、性能基线与合规约束

性能基线不是“跑得快不快”,而是“在什么负载下、什么指标达到什么水平”。建议采集 AWR 或 Statspack 的典型时段,记录 DB Time、每秒事务数、Top 等待事件、SQL 执行计划、IOPS 与吞吐。迁移后要用同一套指标对比,才能判断是否达标。合规约束则包括数据驻留区域、加密要求、审计保留期、脱敏规则和访问控制策略。

评估维度采集对象示例值就绪判断
版本v$database.version11.2.0.4 / 19.1911g 需升级
数据量dba_data_files4.8 TB可分批迁移
依赖dba_db_links3 条失效链接需清理
性能AWR DB Time峰值 3200 s/h需压测验证
合规数据驻留区域境内选对应 Region

五、迁移就绪度评估报告

报告不是资产清单的堆砌,而是带结论的决策依据。建议按“就绪、需改造、阻断”三档给出每个迁移单元的评级,并附上阻断项、改造项、建议迁移方式(Data Pump、GoldenGate、RMAN、ZDM)和预估工作量。评级规则要事先定义,避免主观判断。

迁移就绪度评估:从资产事实到评级结论 资产采集 • 实例 / 数据库 / Schema • 版本 / 字符集 / 归档 • 数据量 / 表空间 • 连接入口 / TNS 依赖与特性分析 • DBLink / 同义词 • 外部表 / 目录对象 • Java / AQ / 调度作业 • 物化视图刷新链 性能与合规基线 • AWR DB Time / TPS • Top 等待 / 执行计划 • 数据驻留 / 加密 • 审计 / 脱敏 / 权限 就绪度评级 就绪 需改造 阻断 + 迁移方式 评级判定路径(示例) 版本受支持? 19c / 23ai 依赖可解耦? DBLink / 外部表 性能可复现? 基线对比 合规满足? 驻留 / 加密 四项均通过 → 就绪;任一项需调整 → 需改造;版本不支持或依赖不可解 → 阻断 输出:迁移单元评级 + 阻断项清单 + 建议迁移方式 + 预估工作量

报告落地时,建议每个迁移单元一行,字段包括:单元名称、当前版本、数据量、依赖项、性能基线、合规要求、就绪评级、阻断/改造说明、建议迁移方式、负责人。这样在后续批次规划时,可以直接按评级排序,先做“就绪”单元验证迁移链路,再集中处理“需改造”和“阻断”项。

常见误区:只统计数据库数量而不统计依赖关系,导致割接时才发现应用连接串、DBLink 或外部表路径未同步;只记录平均性能而不记录峰值,导致迁移后压测不达标却找不到基线依据。

完成本节评估后,应得到一份可评审的就绪度报告:资产事实完整、版本与特性结论明确、依赖关系有图有据、性能与合规基线可对比、每个迁移单元都有评级和处置建议。这份报告是后续迁移方案设计、批次划分和风险应对的直接输入。