搞数据库迁移这事儿，说起来简单，做起来全是坑。尤其是Oracle这种重型数据库，动辄几TB的数据量，牵一发而动全身。很多团队一听到“迁移”两个字就头大，怕停机、怕丢数据、怕业务崩盘。但现实是，业务不等人，云化、国产化、版本升级，哪一关都绕不开。今天咱们就聊聊怎么做到零停机平滑迁移，不是纸上谈兵，是实战总结。
先说清楚一个误区：零停机不代表没风险，而是把风险控制在可接受范围内。真正的零停机迁移，核心就三个字——“双活”。什么意思？就是新旧两个数据库同时运行，业务流量能随时切换，用户压根感觉不到背后在换库。比如你用的是Oracle 11g，要迁到19c，或者从物理机迁到云RDS，第一步不是直接倒数据，而是搭建一套同步机制。Oracle自带的Data Guard是首选，它能实现实时日志同步，主库写一笔，备库就同步一笔，延迟控制在秒级甚至毫秒级。但注意，Data Guard默认是物理备库，只读模式，要写数据还得切主。真正要零停机，得配合GoldenGate做逻辑复制，这样两边都能读写，但复杂度也上来了。
我见过最典型的翻车案例，就是某电商公司大促前夜迁库，图省事直接全量导出导入，结果导出花了8小时，导入又花了12小时，业务直接停了一天半。老板气得拍桌子，技术负责人当场辞职。后来复盘才发现，其实他们业务有低峰期，如果提前做好增量同步，根本不用停那么久。正确做法是分三步走：先全量迁移历史数据，再增量同步变化数据，最后切换流量。全量阶段用expdp或RMAN，增量阶段靠日志分析工具，比如Oracle的LogMiner或者第三方工具如Tapdata。全量跑完后，增量同步追上主库的差距，等到两边数据一致，再切DNS或者修改连接串，整个过程业务无感。
但数据同步只是第一步，真正考验人的是数据一致性校验。你辛辛苦苦同步完，结果发现两边对账差了几万条记录，那才叫崩溃。常见坑点有三个：一是大事务未提交，日志还没落盘就被同步了；二是序列号不同步，新库自增ID和旧库对不上；三是时间戳偏差，比如Oracle的SYSTIMESTAMP在不同服务器上可能差几微秒。解决方法是做全量比对，用checksum或者行数统计。小库可以逐行比对，大库得抽样，比如按主键分段，每段取前100条比对。如果发现不一致，别慌，回滚重跑增量同步就行，关键是得有回滚预案。我习惯在迁移前先做一次演练，模拟切库场景，把问题暴露在白天，而不是凌晨三点。
说到演练，千万别省这一步。很多团队觉得“我们业务简单，直接上就行”，结果真到切库那天，发现应用连不上新库，报ORA-12514 TNS监听错误。为什么？因为连接串里SERVICENAME写错了，或者TNSNAMES.ORA配的是旧库IP。更隐蔽的问题是应用层做了连接池，池子里还留着旧库的长连接，切完库后应用没刷新，继续往旧库写数据，造成数据分裂。所以演练要模拟全流程：先搭建测试环境，复制一份生产数据，然后跑一遍迁移脚本，测试应用是否能正常读写。重点测高并发场景，比如秒杀、支付、订单写入，这些操作对数据库延迟敏感。如果新库响应慢了200毫秒，前端用户可能就感觉到卡顿了。
另一个容易忽略的点是网络带宽。Oracle迁移的数据量通常很大，一张订单表可能几十亿行，索引、分区、LOB字段，全量导出时网络打满，会影响其他业务。我见过一个极端案例：某金融公司迁库，数据量20TB，千兆网络，理论传输时间要55小时，但实际因为丢包重传，跑了整整4天。没办法，只好用快递寄硬盘，物理运输。所以，如果数据量超过10TB，建议走专线或者用阿里云、AWS的迁移服务，他们支持并行传输和断点续传。注意，千万别用公网传敏感数据，加密后再传，避免泄露。
聊切换策略。零停机不是一口气切完，而是灰度切流。比如先切10%的读流量到新库，观察几分钟，看应用报错率和响应时间。没问题再切20%，逐步增加到100%。这个过程中，旧库不要马上销毁，保留24小时作为回退点。万一新库挂了，业务还能秒级切回。我习惯在切换前打一个全局检查点，记录所有会话的SQLID和事务状态，这样万一出问题，能精确知道哪些操作需要补偿。比如某个用户在切换瞬间提交了订单，旧库没来得及同步，那新库里就少了一条记录，得人工补录。
说到底，数据库迁移不是技术活，而是管理活。你需要的不是最牛的工具，而是最稳的流程。把每个环节拆解清楚，预判所有可能出错的点，然后一遍遍演练到肌肉记忆。等到真上生产那天，你会发现，零停机没你想的那么玄乎，不过是把每一步都做扎实了而已。
