我最近帮朋友折腾了一台老服务器，里面跑着 SQL Server 2008 R2 的数据库。这个公司用了快十年的系统，数据量已经堆到几百 GB，硬盘嘎嘎响，随时有崩掉的危险。他咬牙买了台新机器，然后把数据库迁移的重任甩给了我。说实话，这种老版本数据库迁移，看似简单，坑却很多。你以为只要拷贝文件、还原备份就完事了？天真了。SQL 2008 R2 是 2010 年的产物，和现在的主流系统、高版本 SQL Server 之间的兼容性问题会让人抓狂。我上手后第一件事就是提醒他：别急着动生产环境，先搭个测试环境跑一遍流程，不然出问题连后悔药都买不到。
迁移的第一步不是动数据库，而是摸清家底。你得知道库里到底装了多少东西，哪些表是核心业务，哪些是历史归档，还有存储过程、触发器、视图等对象，是否用了过时的特性，比如旧的连接语法或废弃的数据类型。我打开 SSMS 连上老服务器，先跑了 看看所有库的大小，再查了兼容性级别。SQL 2008 R2 默认是 100，如果要迁到 SQL 2016 或更高版本，得先确认应用能否承受升级。这里有个容易忽略的细节：老版本里的扩展存储过程（如 ）在高版本里默认禁用，如果业务依赖它，迁移后需要手动打开，而且可能因为权限问题直接报错。我建议做一份完整的对象清单，包括索引、作业、用户权限，这些东西丢了，业务恢复起来比数据库本身还麻烦。
备份和还原是最常规的操作，但也是最容易出幺蛾子的环节。我选了全备份，因为数据量大，日志备份没必要带过来。先把老库的备份文件压缩，传到新服务器上，然后执行 。新机器装的是 SQL Server 2019，我特意选了和老库一样的兼容性级别 100，避免语法差异导致查询报错。还原过程中，我盯着进度条，顺便检查文件路径是否匹配——很多人栽在这里，老库的数据文件在 D 盘，新库默认在 C 盘，不改路径直接还原会报文件不存在。还有一点：如果有全文索引，恢复后必须重建，这玩意儿和版本绑定很紧。我还立即跑了一遍 ，确保数据完整性没有受损。这一步不能省，因为备份文件在传输过程中可能损坏，尤其是网络不稳定时。
迁移完了，你以为就万事大吉了？真正的麻烦才刚开始。新服务器上的 SQL 2019，默认配置和 2008 R2 完全是两回事。比如最大并行度、内存分配、数据库自动收缩等参数，老库可能用了多年积累的调优设置，新库却是出厂默认值。我检查后发现，虽然兼容性级别设成了 100，但查询优化器在 2019 上仍会有行为变化，尤其是那些依赖旧版优化器规则的查询，性能可能忽高忽低。解决办法是启用旧版基数估计，使用跟踪标志 9481 或数据库作用域的 选项。我建议跑一次压力测试，把业务系统的核心操作模拟执行，看看是否出现慢查询或死锁。别等用户反馈再救火，那会被骂死。
数据层之外，还有一堆附属设施要搬。登录名和密码是常见遗忘项。老库上有几十个应用账号，每个账号都有对应的服务器角色和数据库权限，光靠还原数据库是带不过来的。我用了 这个微软提供的脚本，把登录名的哈希值导出来，在新服务器上重建。脚本在网上能搜到，但要注意版本差异，2008 R2 的哈希算法和 2019 不完全兼容，有时密码会失效，用户需要重新设置。还有 SQL Agent 作业，老库上可能有定时备份、数据清理等任务，这些作业的定义存放在 系统库里，不能直接迁移。我手动导出了每个作业的 T‑SQL 脚本，逐个在新服务器上创建，并调整调度时间，避免与现有任务冲突。链接服务器也得重新配置，因为服务器名变了，原来的连接字符串全部需要改。
说到连接字符串，这又是个坑。老业务系统的配置文件里写的是老服务器的 IP 和实例名，迁移后如果不改，应用根本连不上新库。我帮朋友检查了所有涉及数据库连接的地方：Web 应用的 config、桌面应用的 config、以及那些写死连接字符串的存储过程。改完连接字符串后，还得考虑防火墙和网络策略。新服务器可能换了网段，或者用了不同的端口号。如果 SQL Server 默认的 1433 端口被公司安全策略封了，就得用非标准端口，这时连接字符串必须显式指定端口号。我建议做一次全网段的连通性测试，用 或 命令，确认所有应用服务器都能访问新数据库。别小看这一步，我曾见过一个客户，数据库迁了三天才发现有个老系统连不上，查了整整一天才发现是 DNS 缓存没有刷新。
我想聊聊迁移后的善后和风险兜底。别急着关机或格式化老服务器，至少保留一个月，作为回退方案。很多人迁移完就觉得万事大吉，结果新环境出现诡异的性能问题，老库已经删了，只能从头搭建，数据丢失风险极大。建议设置观察期，监控新服务器的 CPU、内存、磁盘 I/O，同时对比老库的历史性能基线。如果发现某个查询在新库上慢了十倍，不要慌，先分析执行计划，看看是否统计信息没有更新。执行 ，强制刷新所有表的统计信息，很多时候性能问题就能解决。另外，别忘了更新所有文档和运维手册，把新服务器的 IP、实例名、登录方式、备份策略都写清楚。这样即使你不在场，别人也能接手维护。数据库迁移不是单纯的技术活，它考验的是对整个业务系统的理解，以及处理意外情况的耐心。做好每一步，才能让这台老数据库在新机器上继续安稳服役。
