Oracle数据库迁移实战：从11g到19c的完整流程与排坑指南

最近刚做完一套 Oracle 11.2.0.4 核心库到 19c 的迁移总算能坐下来把这套流程整理清楚。数据库迁移这活看上去就是“搬数据”实际上从版本兼容、对象盘点、工具选型到夜里的回切验证每一环都可能翻车。这篇内容主要写给准备做 Oracle 迁移的运维和 DBA 同学也适合需要配合迁移的研发看看迁移到底迁什么、用哪种工具、怎么准备、踩坑怎么排查。我先说个结论Oracle 迁移本身不难难的是把一个运行多年的老库无差别地搬到新环境。老系统里那些没人记得的 DB Link、定时 JOB、自定义角色、ACL 授权、奇怪字符集才是迁移过程中真正会卡住你的东西。这篇文章会完整讲一遍从评估到上线的实操思路并附上我这次实际用到的命令和排查链路。1. 先搞清楚“迁”的是什么版本、平台还是机房很多人一上来就问“怎么把 Oracle A 库迁到 B 库”但“迁移”这个词在不同场景下含义差别很大选错方向后面全乱。我习惯把它拆成三个维度看版本、平台、位置。1.1 版本迁移与平台迁移不能混为一谈版本迁移最常见比如从 Oracle 11.2.0.4 升到 19c。这类迁移核心是“跨版本兼容性”SQL 语法、隐含参数、数据字典结构、字符集行为都可能变化。老库上能跑的 SQL 在新版本不一定能跑或者执行计划变了。更麻烦的是一些老版本里被保留的隐藏功能到了新版本可能直接失效。平台迁移则是换操作系统或换硬件架构比如从 AIX 迁移到 Linux从 Solaris 迁移到国产化服务器或者从物理机迁到虚拟化平台。平台迁移往往伴随版本迁移一起做但如果没有版本变化只是同版本换操作系统通常更适合用物理迁移手段比如 RMAN 恢复或者可传输表空间因为这些工具不关心字符集和 SQL 兼容性直接搬数据文件。还有一种最容易让人混淆的是“机房迁移 / 云迁移”。表面上你只是换了一个机房或者把库迁到云上但网络延迟、存储性能、主机命名规范、监听配置、备份策略全都要重新适配。我之前见过一个项目数据导过去只用了两个小时结果应用连不上原因仅仅是云环境的安全组没放通数据库端口这种问题不在数据库本身却在迁移项目里占了很大时间。所以接到迁移任务先别急着导数据。第一步应该问三个问题目标库版本是多少目标平台是不是同一套网络和部署位置有没有变化答案不一样后面的工具选型完全不同。1.2 逻辑迁移与物理迁移的边界从技术实现上Oracle 迁移就两条路逻辑迁移和物理迁移。逻辑迁移是“把对象和数据重新生成”。典型代表就是 Data Pump 的 expdp 导出、impdp 导入它读取源库的数据和 DDL在目标库重新执行生成一套新的数据文件。优点是灵活可以按 schema 迁、按表迁、顺便改用户名、改表空间名缺点是重建过程会丢失一些底层属性和性能特征而且大表全量导出导入的速度比物理文件拷贝慢。物理迁移是“把数据库文件原样搬过去”。典型代表是 RMAN 备份恢复、可传输表空间、Data Guard 备库切换。它直接处理数据文件、控制文件最大程度保留原有存储布局和性能特性速度通常更快但对目标环境的版本、平台、字节序有严格要求。同一版本同平台RMAN 恢复是最高效的迁移方式跨版本跨平台物理迁移就受限很多。逻辑迁移和物理迁移不是互斥的实际项目里经常混用。比如我们可以用 Data Pump 搬数据再用可传输表空间加速某个超大分区表或者先用 Data Guard 做在线同步最后短停切换完成迁移。明白了这两种边界再看后面的工具对比就清晰多了。2. 动手前必须完成的准备工作少一项都会翻车Oracle 迁移最怕的不是迁移本身而是“以为自己准备好了”。我这次迁移前花了两天专门做盘点最后发现源库里有 17 个 DB Link、3 个自定义角色、一个加了 FGA 审计策略的业务 schema、还有一堆没人维护的自建 JOB。这些东西如果漏掉数据导过去应用照样能起但业务会在一周内陆续报故障。2.1 盘点家底从表空间到 DB Link 一项不漏盘点范围不能只盯着表和索引。我把老库的家底分成五层数据层、对象层、权限层、运行层、外部依赖层。数据层包括表空间、数据文件、表、分区、LOB 段、索引、约束、触发器、序列。要重点关注大表和大分区。超过 100GB 的表expdp 导出虽然能跑但并行度和网络传输都要单独规划。序列是特别容易忽略的迁移后应用如果继续插入数据序列值不对就会主键冲突。对象层包括视图、物化视图、同义词、包、存储过程、函数、类型定义。物化视图要特别注意它本质上有底层表和定时刷新机制Data Pump 导入后往往需要重新编译或重建。同义词容易造成“数据看不见”的假象尤其是 public 同义词导入后如果对应用户不存在应用查询就会报 ORA-00942。权限层包括用户、角色、系统权限、对象权限、表空间配额、profile、密码策略。expdp 导出时如果用 FULL 模式角色和授权通常会带上但带上也不代表导入后完全一致很多坑出在默认表空间不同、临时表空间未指定、权限对象不存在导致授权时报错。运行层包括 DB Link、JOB、队列、调度程序、审计策略、VPD 行级安全策略、ACL 网络访问控制。这一层是最少被盘点的。比如 DB Link 导入后指向的还是源库的连接串如果你把源库下掉相关视图和存储过程就会开始报错ACL 不重建应用调用 UTL_HTTP 会直接抛权限异常。外部依赖层比较杂包括 tnsnames.ora、监听配置、环境变量、启动脚本、备份脚本、监控脚本。这些不属于数据库对象但迁移后切库时少了任何一项都会手忙脚乱。盘点建议直接查数据字典而不是翻文档。我常用的查询大概是这样-- 用户与默认表空间 SELECT username, default_tablespace, temporary_tablespace, profile FROM dba_users ORDER BY username; -- 表空间与数据文件 SELECT tablespace_name, file_name, bytes/1024/1024 AS size_mb FROM dba_data_files; -- 对象分类型统计 SELECT owner, object_type, COUNT(1) FROM dba_objects GROUP BY owner, object_type ORDER BY owner, object_type; -- DB Link 清单 SELECT owner, db_link, host FROM dba_db_links; -- JOB 清单 SELECT job, owner, what, enabled FROM dba_jobs;做完这些查询后把结果整理成一张迁移清单表每类对象对应一个“是否处理”的列。这张表后面做验证时也要用到所以不留死角。2.2 评估停机窗口与 RTO/RPO迁移必须有明确的时间目标。RTO 是业务最多能容忍恢复多久RPO 是允许丢多少数据。大多数核心库迁移要求 RPO 为 0也就是源库切掉之前所有已提交数据必须完整落到新库。如果 RPO 为 0通常要么做一次完整停业务导出导入要么用 Data Guard/GoldenGate 这类同步工具先拉齐增量再切换。如果业务允许 5 到 10 分钟停机Data Pump 全量导出导入往往是最简单可控的方案但如果源库数据量很大比如几个 TB停机时间内根本导不完就得考虑物理迁移加增量日志应用或者先把流量切到新库再反向同步回源库。这里有个我常用的估算法先拿一个 schema 做全量 expdp记录吞吐量再根据总数据量推算真实迁移时间。计算公式很简单预估时间 ≈ 总数据量 / 实测导出吞吐量 × 冗余系数冗余系数我一般取 1.5 到 2因为生产环境的存储并发、网络带宽、目标库导入并行度都会影响最终速度。比如实测 expdp 吞吐量是 200GB/小时数据总量 500GB那预计导出需要 2.5 小时导入再加一倍整体可能要到 8 小时以上。这个数据不提前测等到迁移当天才知道跑不完那就被动了。还有一个很容易被低估的是“切换前最后一次增量导出”。全量迁移完成后从开始导出到业务停止这段时间里源库还有新数据进来切换时通常还需要补一次增量。如果遗忘这一步RPO 直接变成全量导出时间点数据丢失不可接受。2.3 兼容性检查版本、字符集、参数兼容性检查主要看三块版本升级路径、字符集、初始化参数。Oracle 升级路径有官方规则。数据库迁移不是所有版本都能任意直连需要确认目标版本是否支持从源版本直接迁移。11.2.0.4 迁到 19c 是常见的受支持路径但如果源库是很老的 9i 或 10g就得考虑先升级到中间版本再升到目标版本。这一步最好在项目初期确认而不是等到导出导入中途才发现目标库不认老对象。字符集是最容易出隐蔽问题的地方。源库的 NLS_CHARACTERSET 和目标库不一致时纯英文数据可能没感觉但中文数据导入后会出现乱码或 ORA-02374 转换错误。最稳妥的做法是目标库使用与源库相同或兼容的字符集比如源库 ZHS16GBK目标库也建 ZHS16GBK如果目标库用了 AL32UTF8ZHS16GBK 数据通常能无损迁移但导入过程中必须保证 Data Pump 客户端的环境变量 NLS_LANG 正确否则客户端和服务器之间的转换可能导致数据损坏。进入新环境后最好先查一下源库和目标库的核心参数差异SELECT name, value FROM v$parameter WHERE name IN ( db_block_size, compatible, processes, sessions, open_cursors, memory_target, sga_target, pga_aggregate_target, db_files, undo_tablespace, nls_length_semantics ) ORDER BY name;重点看compatible参数。源库 compatible 老目标库 compatible 新导入一般没问题反过来如果目标库 compatible 设置过低部分对象可能建不出来。另外nls_length_semantics如果从 BYTE 改成 CHAR涉及 CHAR/VARCHAR2 字段长度的行为会变化可能导致导入时字段长度不够。2.4 演练计划不能省大型迁移一定要做演练。演练不是重新做一遍导出导入那么简单而是要完整走一遍“切流、启动应用、验证、回退”的流程。我见过太多团队做完数据迁移演练却从来没演练过应用启动脚本结果真正切换那晚数据库没问题应用起不来白白浪费停机窗口。演练还能帮你发现一些环境层面的问题比如目标库服务器的 ulimit 限制、系统时区、/etc/hosts配置、磁盘 mount 权限。这些内容在导出导入阶段根本不会暴露但等应用一启动就原形毕露。3. 选哪条路expdp/impdp、RMAN、Data Guard 的适用边界Oracle 迁移工具很多真正常用的就五类Data Pump、RMAN、可传输表空间、Data Guard、GoldenGate。很多人选型只看“哪个快”忽略了自己要迁移的环境限制结果选了不能用的方案。工具/方案迁移维度停机要求跨版本跨平台/字节序难度典型适用场景expdp/impdp逻辑需停机支持支持中中小库、按用户迁移、可调整表空间/用户RMAN 备份恢复物理需停机有限不支持字节序变化低同版本同平台克隆、容灾恢复可传输表空间物理逻辑较短支持支持字节序转换高大库迁移、跨平台迁移Data Guard 备库切换物理日志分钟级需在线升级配合不支持跨平台高大库在线迁移、容灾切换GoldenGate逻辑复制秒级支持支持异构很高在线迁移、异构迁移、双活架构Data Pump 是我用得最多的因为它的测试成本低、可控性强。导错了重新导就行目标库不会存在半残的数据文件。缺点是整体速度受 SQL 重建限制大对象和索引较多时导入时间会比较长。对于几十 GB 到一两百 GB 的库Data Pump 是首选。RMAN 的优势是快。它是纯物理拷贝不需要把每条记录重新插一遍。但用 RMAN 做跨版本迁移限制很多主流做法是在同版本同平台环境先物理恢复再用升级工具把数据库版本升上去。等于说“RMAN 负责快升级工具负责版本”。如果你只是要在一个新服务器上克隆一套同版本库RMAN 最合适。可传输表空间特别适合大库跨平台迁移。它把数据文件直接搬过去再用 Data Pump 只导元数据。相比全量 Data Pump它不需要重建数据速度优势明显。但操作链路复杂先要自包含检查再转换字节序再把数据文件注册到目标库最后导元数据。做完一次后你会有种“其实也不难”的感觉但第一次做一定要充分演练。Data Guard 迁移的核心思路不是“搬数据”而是“同步状态”。先在目标环境搭一套备库源库的日志不断应用到备库迁移窗口到来时激活备库完成切换。它天然支持接近零停机的迁移适合 TB 级大库。但要求源库和目标库必须同平台同字节序版本也要满足 Data Guard 兼容要求否则日志应用会报错。GoldenGate 是能力最强的可以异构复制也可以做双向复制但部署和运维成本都高。除非业务要求秒级切换或者必须做异构迁移否则我不建议在普通迁移项目里引入 GoldenGate复杂度不值得。综合来看我的选型建议是数据量不超过 500GB 且停机窗口允许优先 Data Pump同版本同平台要快速克隆用 RMAN大库跨平台先用可传输表空间方案评估TB 级大库且要求短停机考虑 Data Guard 加在线升级只有真正的异构或双活需求才上 GoldenGate。4. 实操一套 Oracle 11g 到 19c 的 Data Pump 迁移完整过程下面用一套实际项目流程展开。源库是 Oracle 11.2.0.4业务 schema 叫 CRM目标库是 Oracle 19c目标 schema 也叫 CRM表空间从 CRM_DATA 改名到 APP_DATA。数据量大约 180GB停机窗口给了 6 小时。4.1 目标库基础准备先在目标库创建表空间和用户。Data Pump 导入时如果用户不存在会报 ORA-01918如果表空间不存在会报 ORA-00959。与其让导入过程反复失败不如一开始就建好。-- 目标库 19c 执行 CREATE TABLESPACE app_data DATAFILE /u01/app/oracle/oradata/NEWDB/app_data01.dbf SIZE 50G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; CREATE TABLESPACE app_idx DATAFILE /u01/app/oracle/oradata/NEWDB/app_idx01.dbf SIZE 20G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; CREATE USER crm IDENTIFIED BY YourStrongPwd DEFAULT TABLESPACE app_data TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON app_data QUOTA UNLIMITED ON app_idx; GRANT CONNECT, RESOURCE TO crm;这里我给目标库建了两个表空间一个放表数据一个放索引。生产环境建议表和索引分开表空间方便管理。Data Pump 导入时能不能自动把索引放到另一个表空间可以靠remap_tablespace加上transformsegment_attributesN来做下面会讲到。4.2 在源库创建 Directory 并导出Data Pump 的 directory 是数据库对象指向服务器本地路径。需要注意的是导出文件必须写到源库服务器能访问的目录而不是随便指定客户端路径。-- 源库 11g 执行 CREATE OR REPLACE DIRECTORY dpump_dir AS /u01/app/oracle/backup/dpump; GRANT READ, WRITE ON DIRECTORY dpump_dir TO system;导出命令建议直接写在 shell 脚本里避免交互式输入密码暴露在历史记录中。我习惯用并行参数和通配符 dumpfileexpdp system/passwordorcl \ directorydpump_dir \ schemascrm \ parallel4 \ compressionall \ dumpfilecrm_%U.dmp \ logfileexp_crm.log \ excludestatistics几个参数我解释一下parallel4表示开 4 个并行进程。并不是越大越好受服务器 CPU 和 IO 限制一般先按 CPU 核数的一半试再用日志观察是否成为瓶颈。compressionall用来压缩导出文件。11g 之后把 COMPRESSION 设置为 ALL可以压缩表数据和元数据。经验是压缩率能达到 50% 以上传输时间能省很多代价是导出时 CPU 会升上去。dumpfilecrm_%U.dmp配合parallel个位数字%U会生成多个分片文件比如 crm_01.dmp、crm_02.dmp。如果没有%U并行导出会报错或者只有一个文件写入达不到并行效果。excludestatistics先不导优化器统计信息。老库的统计信息有可能基于旧版执行计划算法直接带到 19c 反而容易生成糟糕的执行计划。导入完成后重新收集统计信息更稳。导出完看日志末尾。出现类似Job SYSTEM.SYS_EXPORT_SCHEMA_01 successfully completed字样才算成功。如果没有成功不要进入下一步。对于大库导出过程中要持续关注磁盘空间。180GB 库压缩后大概 80GB 左右导出目录至少要预留 100GB防止中途写满。导出日志里如果看到ORA-01691这类错误通常是目录路径权限不对先排查 Linux 目录的写权限和属主再排查 Oracle 的 directory 对象权限。4.3 文件传输与导入导出完成后把 dump 文件传到目标库服务器。传输工具看网络条件我常用 rsync因为它支持断点续传和限速rsync -avP --bwlimit100000 \ /u01/app/oracle/backup/dpump/crm_*.dmp \ oraclenewserver:/u01/app/oracle/backup/dpump/这里--bwlimit100000把带宽限制在 100MB/s 左右避免占满业务网段带宽。传输完立即做一次 md5 校验防止文件在大流量传输中出现静默损坏md5sum /u01/app/oracle/backup/dpump/crm_*.dmp source.md5 md5sum -c source.md5目标库上同样需要建好 directory 并授权然后执行导入impdp system/passwordnewdb \ directorydpump_dir \ dumpfilecrm_%U.dmp \ schemascrm \ remap_schemacrm:crm \ remap_tablespacecrm_data:app_data,crm_idx:app_idx \ transformsegment_attributesN \ parallel4 \ logfileimp_crm.logremap_schemacrm:crm看着好像没变化但它的含义是把源 schema 映射到目标 schema。如果不想改用户名可以省略但如果你想把 CRM 正式库导到测试库并改名就必须用这个参数。remap_tablespace用来改表空间。这里把源库的CRM_DATA映射到目标库的APP_DATA把CRM_IDX映射到APP_IDX。transformsegment_attributesN是比较关键的一个参数。它等于告诉 Data Pump导入时忽略原有对象的段属性比如物理属性、存储子句、默认表空间等全部落到目标用户的默认表空间上。这样即使源表指定了别的表空间导入后也会统一落在CRM用户默认表空间APP_DATA上配合 remap 能让物理布局干净很多。导入最怕“干到一半报错退出”。遇到单对象错误时先不要慌Data Pump 默认会把错误记到日志里并继续尝试导其他对象。等日志跑完再统一看错误列表。不要一出现 ORA 错误就 CtrlC那往往会把本来能完整导入的库搞到半成品状态。4.4 导入后立即处理无效对象目标库导入完成后第一步不是启动应用而是编译无效对象。大量存储过程、函数、视图导入后处于 INVALID 状态这是正常的因为对象依赖的对象还没有全部建好。sqlplus / as sysdba $ORACLE_HOME/rdbms/admin/utlrp.sqlutlrp.sql 会自动重编译所有无效对象。跑完后再查一次SELECT owner, object_type, status, COUNT(1) FROM dba_objects WHERE status VALID GROUP BY owner, object_type, status ORDER BY owner, object_type;如果仍有无效对象基本就是源库本身就存在无效对象或者是依赖的 DB Link、对象权限没有补齐。逐个打开错误信息即可。4.5 重新收集统计信息因为导出时excludestatistics导入后所有对象没有统计信息或者在导入最近一次用DBMS_STATS收集。19c 下建议用默认参数收集 schema 统计信息EXEC DBMS_STATS.GATHER_SCHEMA_STATS(ownname CRM, cascade TRUE, degree 8);收集时间取决于对象数量和数据量。180GB 的库大概需要 30 分钟到 1 小时。统计信息不收集完不要急着上线否则应用第一次查询可能选出极差的执行计划。5. 迁移过程中的高频故障与排查链路无论准备多充分迁移中都可能报错。下面这几个是我这次以及过往项目中遇到的高频问题排查链路讲得细一些遇到同类问题可以少走弯路。5.1 ORA-39083 / ORA-01918目标用户或表空间不存在这个错误几乎是每个第一次用 Data Pump 的人都会遇到的。日志里主错误是ORA-39083: Error creating object C##TYPE_BODY后面跟着具体 ORA-01918: user CRM does not exist。排查链路很简单用目标库查询dba_users确认用户是否存在。如果用户不存在新建用户并赋予必要的角色和权限。如果用户存在再看默认表空间是否存在用户有没有对应表空间配额。导入完成后如果权限对象报错通常是在导入用户对象之前授权的目标对象还没建好。这时不要盲目重导等全部导入完成后用GRANT语句补齐即可。一个常见误区是以为 Full 模式导出导入会自动建用户。实际上 Data Pump 在全库导入时确实会尝试创建用户但 schema 级导出导入不会所以schemascrm这种方式必须预先确保目标用户存在。5.2 ORA-31684对象已存在如果目标库之前做过多轮导入或者用户下已经残留同名表就会报ORA-31684: Object CRM.T_ORDER already exists。排查链路先判断残留对象是否有数据。如果只是空表结构可以留着导入时用table_exists_actionskip跳过。如果残留对象里有脏数据且你想让导入覆盖它用table_exists_actionreplace。这个参数会先 drop 再建代价是可能丢失表上的依赖对象比如触发器、外键需要后续重新处理。如果只更新部分数据可以用table_exists_actiontruncate它会清空数据再导入。我一般不建议直接设置table_exists_actionreplace跑完整库因为可能导致大量外键约束重建也容易掩盖别的问题。更稳妥的做法是先清空目标 schema再重新导入。比如-- 目标库确认可以清空后执行 BEGIN FOR r IN (SELECT table_name FROM user_tables) LOOP EXECUTE IMMEDIATE DROP TABLE || r.table_name || CASCADE CONSTRAINTS; END LOOP; END; /5.3 ORA-02374 与字符集转换问题ORA-02374 这类错误通常出现在源库字符集和目标库字符集不一致时报错信息里还会带一句 “conversion error” 相关的说明。排查链路先查源库和目标库的 NLS 参数SELECT parameter, value FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET,NLS_NCHAR_CHARACTERSET,NLS_LANGUAGE,NLS_TERRITORY);如果源库是 ZHS16GBK目标库是 AL32UTF8正常是兼容的。问题是执行 impdp 的客户端进程必须有正确的NLS_LANG。比如我在 Linux 服务器上执行导入就要设置export NLS_LANGSIMPLIFIED CHINESE_CHINA.ZHS16GBK不要以为目标库是 AL32UTF8客户端 NLS_LANG 就一定要设成 UTF8。Data Pump 导出文件里已包含了字符集元数据导入时客户端 NLS_LANG 的主要作用是告诉进程如何解释外部数据。设错了中文数据就可能在导入时发生二次转换轻则乱码重则 ORA-02374。如果目标库字符集和源库不兼容比如源库 AL32UTF8 里有一堆 emoji目标库却是 ZHS16GBK那么先不要强制导入。要么改源数据要么重新评估字符集否则导入后的数据已经损坏后期修复成本极高。5.4 ORA-01653 / ORA-01658导入时表空间空间不足导入大表时报ORA-01653: unable to extend table CRM.T_LOG by 128 in tablespace APP_DATA或者建表时报 ORA-01658说明目标表空间容量不够。排查链路查看目标表空间使用率SELECT tablespace_name, SUM(bytes)/1024/1024 AS used_mb FROM dba_segments WHERE tablespace_name IN (APP_DATA,APP_IDX) GROUP BY tablespace_name; SELECT file_name, bytes/1024/1024, autoextensible, maxbytes/1024/1024 FROM dba_data_files WHERE tablespace_name IN (APP_DATA,APP_IDX);如果表空间没有开启自动扩展就需要手工加数据文件如果开启了自动扩展但 maxsize 设置太小也需要扩容。最容易踩的坑是你把表数据 remap 到了一个新表空间但源库表定义里有STORAGE子句或者INITIAL参数特别大导入后每个段都申请了超大初始区。遇到这种情况用transformsegment_attributesN能一定程度上抹掉存储子句但已有的 extent 已经产生还是要把表空间容量预留足。5.5 导入后 JOB、DB Link、ACL 缺失这类问题最隐蔽因为它不在日志里报 ORA 错误而是上线几天后才暴露。比如定时任务没有在目标库重建或者应用调用 UTL_HTTP 时权限不足。如果要在 Data Pump 导入后重建 JOB先查源库的 JOB 定义再在目标库执行 DBMS_SCHEDULER 脚本。Data Pump 对 DBMS_SCHEDULER 的兼容性不如老式 DBMS_JOB经常出现导入后 job 被 disabled 的情况。导入完成后要主动检查SELECT owner, job_name, enabled, state FROM dba_scheduler_jobs ORDER BY owner, job_name;如果 job 被 disabled用DBMS_SCHEDULER.ENABLE重新启用就好。但如果 job 里引用的是源库表或源库 DB Link哪怕 enable 了也会执行失败。DB Link 导入后需要确认它指向的目标是否还是原来的库。如果源库停机后要废弃源库上的 DB Link 就应该重新创建指向新库或者用目标库的新连接串替换。这条链接如果忘记改很多报表查询还是会跑到老库上去DBA 调了半天才发现查的是旧连接。ACL 是 11g 之后访问外部网络必须配置的。如果老库应用有 UTL_HTTP 请求第三方接口迁移后必须重建 ACLBEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host api.example.com, ace xs$ace_type(privilege_list xs$name_list(http), principal_name CRM, principal_type xs_acl.ptype_db)); END; /5.6 执行计划变差有时数据导入完成应用也能连上但业务查询突然变慢。最常见原因是统计信息缺失或者 19c 优化器对老 SQL 的估算方式和 11g 不同。排查链路先看目标库有没有统计信息一般DBA_TAB_STATISTICS里 LAST_ANALYZED 为 NULL 就说明没有收集。重新执行DBMS_STATS.GATHER_SCHEMA_STATS。如果依旧慢用DBMS_XPLAN.DISPLAY_CURSOR看实际执行计划对比源库。重点看表的基数估算是否偏差巨大有没有出现FULL TABLE SCAN而源库走的是索引范围扫描。如果只有个别 SQL 异常可以用 SQL Plan Baseline 固定原执行计划或者加查询提示。我建议先收集完统计信息再观察直接上 Baseline 有时会掩盖更深的问题。6. 迁移完成后的核对清单和上线切换建议导入完成、无效对象编译完、统计信息收集完不代表可以切业务。我习惯在正式切换前再做一轮“双库核对”从数据完整性到应用功能逐项验证。6.1 数据完整性核对核对数据不是只数行数而是分层验证对象数量核对按 owner object_type 对比源库和目标库确认表、视图、索引、触发器、包等对象数量一致。行数核对对核心表执行 count。大表 count 很耗时可以抽样重要表或者用DBMS_STATS.GET_TABLE_STATS里的 num_rows 对比但最终还是要抽查几张核心表做全量 count。序列核对源库中每个序列取LAST_NUMBER目标库也取LAST_NUMBER确保一致或目标库值大于源库。应用插入新数据时序列值如果小于现有主键最大值会立刻出现主键冲突。其中行数核对我推荐用如下方式快速生成脚本SELECT SELECT || table_name || AS tbl, COUNT(*) AS cnt FROM || table_name || ; AS sql_text FROM user_tables ORDER BY table_name;把生成的 SQL 在源库和各目标库跑一遍把结果导出文件对比差异一望即知。6.2 应用与业务验证DBA 能做的数据验证只是基础业务验证必须由应用测试人员介入。我这次迁移中应用侧验证清单包括登录验证关键业务账号能否正常登录。增删改验证在业务测试账号下做几条事务确认能成功提交和回滚。报表验证跑几份日结或月结报表和数据比对是否一致。定时任务验证第二天早上观察 JOB 是否按计划执行。外部接口验证调用支付、短信、邮件等接口确认 ACL、UTL_HTTP 权限正常。这里我踩过一次教训迁移后应用能登录但所有工单号都显示为空查到最后是 package body 里一个公共同义词指向了旧库的视图源库一停查询就报错。这种问题只有靠业务验证才能发现DBA 的 SQL 统计验证完全看不到。6.3 切换与回退方案切换前设计好回退方案并且回退方案要提前演练过。Data Pump 迁移的天然回退手段是保留源库不着急下电。切换窗口内如果目标库应用验证发现问题直接把应用指回源库即可。但这里有条前提源库不能停写。如果切换时业务已经发到源库源库要继续对外服务那么回退很容易如果源库已经停止服务并处于只读状态回退后业务会丢失切换窗口到回退前的新数据。所以我的建议是分两步走第一步源库保持可读可写目标库完成数据全量同步 最后一次增量导入应用先切到目标库。第二步观察期一般 24 到 72 小时内如果新库稳定再让源库进入只读归档状态如果新库出问题应用立即回切到源库几乎无损。观察期结束后记得在目标库做一次全量备份。很多团队迁移完就放松了结果新库跑了三天没备份一旦出问题连恢复介质都没有。备份完成后再考虑下线源库源库数据文件可以保存一段时间作为最后兜底。6.4 我自己的收尾习惯等应用完全跑稳我会再花半天把这次迁移的文档补完包括源库和目标库版本信息、迁移命令、导入日志、DB Link 清单、ACL 配置、回退步骤。信息不全的迁移文档等于没有文档下一个人接手时还得重新猜一遍。另外我会主动清理迁移产物比如源库空目录下的 dump 文件、临时导入日志、测试用账号。这类文件看似无害但会占用空间也可能被安全扫描标记为敏感数据。数据文件该压缩归档的归档该删除的删除别留一摊烂摊子。数据库迁移这事情难就难在“没人替你踩过的坑你大概率还要踩一遍”。工具原理就那么几件事真正区分好坏的是准备够不够细、验证够不够狠、回退够不够快。希望这篇内容能让你在动手前把该想到的都想到少走几段夜路。