上个礼拜，一个老朋友深夜给我打电话，说他公司那套跑了八年的Oracle数据库，终于扛不住了。业务量翻了三倍，查询慢得像蜗牛爬，老板天天拍桌子。他说要迁移，但面对市面上五花八门的方法，整个人懵了。这不奇怪，Oracle迁移这事，听着就让人头大。但其实拆开来看，无非就是五种主流方式，各有各的脾气秉性，选对了路子，比想象中省心得多。
先说说最简单粗暴的——逻辑导出导入。这招用EXPDP和IMPDP命令，把数据从源库卸出来，再塞进目标库。优点是上手快，你只要会敲命令行，基本就能搞定。适合数据量不大的场景，比如几十GB的数据库，或者你只迁移部分表。缺点也明显，速度慢得像老太太过马路，几百GB的数据跑起来，你等着熬通宵吧。而且遇到大字段或者特殊对象，容易翻车。我见过一个案例，有人拿这招迁移1TB的库，跑了整整三天，中间还断了一次，差点把人搞崩溃。所以，小打小闹可以，大项目千万别指望它。
第二种方式，数据泵加传输表空间，算是逻辑导出的升级版。它把表空间整体打包，连数据文件一起搬过去。好处是速度快，因为直接复制文件，不用一条条记录去解析。尤其适合那些表结构复杂、数据量大但表空间划分清晰的库。操作也不难，先让表空间只读，然后导出元数据，搬完文件后再导入。不过有个坑——源和目标库的版本、操作系统必须兼容，不然后患无穷。我之前帮一个客户迁移，源库是Linux上的Oracle 11g，目标库是Windows上的19c，结果传输表空间直接报错，只能换方法。这东西就像搬家时用集装箱，省事，但得先确认你家门够宽。
第三种，流复制和Data Guard，这俩是Oracle亲儿子。Data Guard主要用于灾备和热迁移，它靠日志同步保持主库和备库一致，切换时几乎零停机。流复制则更灵活，能指定同步哪些表，甚至做双向同步。适合对业务连续性要求极高的场景，比如金融系统或者电商平台，停机一分钟损失几十万那种。配置起来有点技术门槛，得懂日志分析、网络延迟控制这些玩意儿。我有个朋友在银行做DBA，他们迁移核心交易系统，用的就是Data Guard，切换前演练了八遍，正式上线只花了三分钟。但话说回来，这东西对网络要求苛刻，带宽不够或者延迟高，日志堆积能把主库拖死。
第四种，GoldenGate，Oracle自家的实时数据同步神器。它能跨平台、跨版本，甚至能从Oracle同步到其他数据库，比如MySQL或者Kafka。原理是抓取日志变化，实时应用到目标端。适合做异构迁移、零停机迁移，或者你需要持续同步的场景。配置复杂度比Data Guard高一档，光参数文件就能写满一页纸。而且它很吃资源，CPU和内存不够的话，抓取进程会慢得像抽风。我见过一个公司用GoldenGate把Oracle迁移到云上，前期调试花了两周，但上线后数据延迟只有几秒，老板直呼真香。不过，小团队慎入，这东西运维成本不低，出了问题排查起来能让人头秃。
第五种，也是最硬核的——手动迁移，或者叫物理迁移。直接复制数据文件、控制文件、日志文件，然后手动重建控制文件、恢复数据库。这招适合那种对Oracle内部机制了如指掌的骨灰级玩家。优点是极端灵活，你爱怎么搞就怎么搞，不受工具限制。缺点也很致命，一步错步步错，文件版本对不上、路径写错了、SCN不一致，都能让你原地爆炸。我年轻时干过这事，迁移一个测试库，结果忘记改一个文件路径，数据库起不来，花了一整天才排查出来，从此发誓非必要不用这招。现实中，这方法主要用于跨平台迁移，或者当你被逼到绝路，其他工具都搞不定的时候。
聊到这，你可能会问，到底该选哪种？其实答案很简单，看你的场景说话。数据量小、时间充裕，逻辑导出导入最省心。数据量大但结构规整，传输表空间是性价比之王。业务不能停、要求零宕机，Data Guard或GoldenGate是必选项。至于手动迁移，除非你是极客或者实在没得选，否则别碰。决定之前，先问自己三个问题：数据有多大？业务能停多久？团队技术储备够不够？这三个问题想明白了，80%的纠结就没了。
补一句，无论选哪种方法，测试一定要做足。我见过太多人拍胸脯说“没问题”，结果迁移完发现数据对不上、索引失效、存储过程报错，只能回滚。所以，先在测试环境跑一遍，记录每一步的耗时和坑点。正式上线前，找个周末，拉上运维和业务方，搞一次全流程演练。别嫌麻烦，数据库迁移这东西，慢就是快，稳就是赢。
