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.version | 11.2.0.4 / 19.19 | 11g 需升级 |
| 数据量 | dba_data_files | 4.8 TB | 可分批迁移 |
| 依赖 | dba_db_links | 3 条失效链接 | 需清理 |
| 性能 | AWR DB Time | 峰值 3200 s/h | 需压测验证 |
| 合规 | 数据驻留区域 | 境内 | 选对应 Region |
五、迁移就绪度评估报告
报告不是资产清单的堆砌,而是带结论的决策依据。建议按“就绪、需改造、阻断”三档给出每个迁移单元的评级,并附上阻断项、改造项、建议迁移方式(Data Pump、GoldenGate、RMAN、ZDM)和预估工作量。评级规则要事先定义,避免主观判断。
报告落地时,建议每个迁移单元一行,字段包括:单元名称、当前版本、数据量、依赖项、性能基线、合规要求、就绪评级、阻断/改造说明、建议迁移方式、负责人。这样在后续批次规划时,可以直接按评级排序,先做“就绪”单元验证迁移链路,再集中处理“需改造”和“阻断”项。
完成本节评估后,应得到一份可评审的就绪度报告:资产事实完整、版本与特性结论明确、依赖关系有图有据、性能与合规基线可对比、每个迁移单元都有评级和处置建议。这份报告是后续迁移方案设计、批次划分和风险应对的直接输入。