搞数据库迁移这事儿，十有八九都是被逼的。不是业务要上云，就是机房要搬迁，再不然就是老库撑不住了得换新机器。每次接到这种任务，我心里都清楚，真正的考验不在技术本身，而在那些你根本预想不到的坑上。Oracle数据库的迁移尤其如此，它不像MySQL那样拷个文件就能跑，从字符集到权限、从序列到触发器，任何一个环节出了岔子，后面就是连锁反应。所以今天这篇东西，我专门把整个迁移拆成五大步，每一步都是实战里踩过雷之后总结出来的，你要是正赶上要干这活儿，照着这顺序走，至少能少熬几个通宵。
第一步，也是往往最容易被低估的一步，就是摸清家底。很多人上来就急着找工具、跑脚本，结果迁到一半发现源库里有张表占了好几个T，或者有个Job每天凌晨三点要跑批，你这边一停库，那边业务直接报警。正经做法是，先花一两天时间把源库的清单理清楚：有哪些用户、哪些表空间、哪些物化视图、哪些DBLINK、哪些定时任务，还有最重要的——数据量到底多大。这里我建议直接查DBASEGMENTS和DBAOBJECTS，别信什么监控平台上的估算值，那些数字往往偏小。同时把数据库版本、补丁级别、字符集这些基础信息记牢，后面选迁移工具和定方案全得靠它们。这一步不图快，图的是后面每一步都能按计划走，而不是边走边猜。
第二步，选迁移方式。这一步没别的，就看你手里有什么资源、能容忍多长的停机窗口。如果是同版本同平台，而且停机时间能控制在两三个小时内，那Data Pump（expdp/impdp）是最稳的，逻辑导出再导入，干净利落。要是数据量特别大，几十个T那种，逻辑导出根本跑不动，那就得考虑物理迁移，比如用RMAN的CONVERT DATABASE，或者直接停库拷贝数据文件加恢复控制文件。还有一种情况是跨版本跨平台，比如从Solaris上的11g迁到Linux上的19c，这种就别想着用物理方式硬怼了，老老实实做逻辑迁移，或者用GoldenGate做在线同步，先追平再切换。这里我得特别提醒一句，别迷信什么“不停机迁移”的鬼话，除非你业务架构本身就能接受分布式事务，否则任何迁移都有窗口，差别只是长短。
第三步，预迁移检查。这一步很多人会跳过，直接开干，但我要说的是，百分之八十的迁移事故都出在预检查没做透。具体查什么？查无效对象——DBAINVALIDOBJECTS，这玩意儿在迁移后往往会激增，因为依赖关系变了，有些同义词、视图、包会失效。源库里如果有无效对象，迁移前就该修掉，别指望导入后自动恢复。查自增序列和主键冲突，尤其那些用了触发器或者序列生成主键的表，导入后序列值经常比表里的最大值还小，一插入就报主键冲突。再有就是外键约束，大表导入的时候，外键能关就关，等数据全进去了再打开，不然导入速度会慢到你怀疑人生。别忘了查大对象（LOB）段，LOB的迁移经常出问题，尤其是CLOB里存了中文的，字符集转换一错，全变成问号。把这些问题在预检阶段都处理掉，后面才能顺畅。
第四步，正式执行迁移，但这里有个节奏问题。我见过太多人，一把梭哈，expdp导出完了直接impdp导入，中途报错就停下来改参数，改完接着导，结果导出来的数据前后不一致，还得推倒重来。正确的做法是分阶段走：先导结构，再导数据，补索引和约束。导结构用impdp的SQLFILE参数先生成DDL脚本，你检查一遍再执行，这样能发现那些因为版本差异导致的语法不兼容。然后导数据时，建议用PARALLEL参数并行跑，但别一上来就设成CPU核数，一般4到8就够了，并行度太高反而会触发资源竞争，把库拖垮。数据导完后，再创建索引和外键，这时候可以开高并行度，因为没数据锁的问题。整个过程一定要写日志，每个阶段结束都去查一下日志里的ORA-错误，哪怕只是警告级别的，也得看清楚原因。
第五步，也是最后一步，验证和数据比对。这一步才是真正决定迁移成败的环节。很多人导完数据一看能连上就宣布成功，这是大忌。验证分三层：第一层，对象数量比对，源库和目标库的表、索引、视图、序列、存储过程数量必须完全一致，这个用SQL查一下DBAOBJECTS按类型分组就能比出来。第二层，数据量抽查，别全量比对，那是生产环境跑不动的，但关键业务表一定要COUNT(*)比对，再抽几张大表看MAX(主键)和SUM(某数值列)是否一致。第三层，业务冒烟测试，找业务方的人来，把核心流程走一遍，比如登录、下单、查询报表，看看有没有功能异常。这里有个小技巧，迁移完成后先别急着切流量，保持源库和目标库并行跑个半天，用日志对比的方式确认两边数据一致了，再正式切换。当然，这个看你们业务能不能接受双写成本，但至少停机切换前，验证这关必须过。
说点实在的。数据库迁移这个活儿，干得好是应该的，干砸了全是你背锅。所以千万别抱侥幸心理，每一个步骤都得有文档记录，每一步都留好回退方案。回退方案怎么写？简单说就是，迁移前的完整备份必须留着，包括数据文件和归档日志，万一新库起不来，至少能退回原系统。另外，迁移过程中所有命令行和响应文件都保存下来，出了问题能复盘。还有一点容易被忽略，就是通知机制——迁移期间要跟业务方、运维方建立实时沟通渠道，每完成一个阶段就同步一次进度，别闷头干，出了问题人家也不知道你在干嘛。
再说说工具层面的选择。现在市面上Oracle迁移工具有不少，除了官方自带的Data Pump和RMAN，还有像Oracle GoldenGate、OEM的迁移插件、甚至第三方工具如Fyrodo和SharePlex。GoldenGate适合那种几乎零停机的场景，但配置复杂度高，而且对源库的归档日志压力很大，得提前规划磁盘空间。OEM的那套迁移工具适合新手，界面友好，但可控性差，遇到问题不好排查。我的建议是，除非你团队里有人对GoldenGate特别熟，否则优先用Data Pump，它是Oracle亲儿子，兼容性最好，遇到bug也有官方文档兜底。至于那种跨云厂商的迁移，比如从AWS RDS迁到阿里云RDS，那基本没得选，只能用逻辑导出，而且要注意云厂商对expdp版本的支持，经常会有坑。
还有一个细节，字符集。这个坑埋得深，平时根本注意不到，但一旦踩中，数据全乱。迁移前务必确认源库和目标库的NLSCHARACTERSET一致，如果不一致，比如源库是ZHS16GBK，目标库是AL32UTF8，那就在导出时指定字符集转换，导入后还要抽样验证中文数据是否正常。这里有个经验值，如果源库和目标库都是中文环境，最好统一用AL32UTF8，因为它是Oracle推荐的通用字符集，能覆盖更多生僻字和特殊符号。万一字符集不一致又没做处理，导进去的数据要么报错，要么显示成乱码，到时候再回头补，工作量翻倍。
还有权限问题。很多人迁移完发现应用连不上库，报ORA-01017，用户名或密码错误，其实根本不是密码错了，而是权限没赋全。Oracle的逻辑迁移默认不导用户权限，所以你在源库上给某个用户授的SELECT ANY TABLE、CREATE SESSION这些权限，到了目标库全得重新授。建议迁移前把所有用户的角色和系统权限列表导出成脚本，导入完成后统一执行一遍。别漏了那些系统账号，比如SYS、SYSTEM的权限也得确认，不然DBA工具可能连不上。
再啰嗦一句，心态。数据库迁移这事儿，急不得，慌不得。每一步都按流程走，每一步都留证据，每一步都做好回退准备，基本不会出大乱子。如果你正在筹划一次Oracle数据库迁移，把这五步挨个过一遍，至少能保证你在迁移当天心里有底。毕竟，数据库迁移的成功标准不是“数据过去了”，而是“业务正常跑，用户没感觉”。祝你好运。
