说到SQL Server 2008数据库迁移，我脑海里立马浮现出几个熬夜加班的夜晚。这个版本的数据库在2019年就停止了主流支持，但很多老系统还在靠它撑着。你问我为啥对这事儿这么熟？因为这两年我帮朋友公司处理过好几回迁移，每次都能遇到意想不到的坑。
先说最常见的场景：从物理机搬到虚拟机，或者从老服务器换到新硬件。很多人以为这是最省事的迁移，直接备份还原不就完了？真这么干过的人都知道，还原后经常遇到权限错乱、作业丢失、链接服务器配置全没的情况。我见过最惨的一次，对方还原完数据库，应用连不上，查了半天发现是SQL Agent服务没启动，而作业全在Agent里挂着。
再说说跨版本迁移，这是另一块硬骨头。从2008迁到2016或2019，不能直接备份还原，得走脚本生成或者使用迁移助手。我试过用脚本方式迁移大库，那个等待时间长得能让人怀疑人生。几百万行的表，脚本跑起来跟蜗牛似的。后来学聪明了，用BCP命令批量导出导入，速度能快上好几倍，但前提是你得先把表结构、索引、触发器这些对象都处理好。
还有个很多人忽略的点：排序规则和兼容级别。2008的默认排序规则可能跟新版不一样，迁移完查询结果排序全乱了。更麻烦的是兼容级别，如果不手动设置，新版本数据库默认用新兼容级别，某些老语法可能直接报错。我习惯迁完第一件事就是改兼容级别到100，然后再慢慢测试哪些功能需要调整。
说到测试，这步千万不能省。我见过有人迁移完直接切生产，结果报表查询慢到超时。原因很简单，统计信息没更新，查询计划全乱了。正确做法是迁完后先跑一遍完整统计信息更新，然后再用生产环境的典型查询做性能对比测试。这步做好了，能省去后面一堆麻烦事。
对了，还有个容易踩的坑是数据库邮件和SSIS包。邮件配置存在msdb库里，直接备份还原主库不会带上。SSIS包一般存在文件系统或SSIS库里，迁移时得单独处理。我朋友去年就栽在这上面，数据库迁完了，客户说收不到通知邮件，查了半天才发现邮件配置压根没迁过来。
说一下迁移工具的选择。微软官方的迁移助手虽然好用，但对2008的支持也就那样。我常用的组合是：小库用备份还原，大库用分离附加，跨版本用工具加脚本。分离附加有个好处，速度极快，但必须确保文件完整，而且操作期间数据库要离线。要是数据库不能停机，那只能用镜像或日志传送这类高可用方案了。
写这篇文章时我特意翻了下自己的迁移记录，发现处理过的项目里，真正顺利的不到三分之一。大多数问题都出在准备不足上——没提前梳理依赖关系，没做充分的兼容性测试，没准备好回滚方案。SQL Server 2008数据库迁移这事儿，说难也难，说简单也简单，关键看你有没有把那些隐藏的坑都提前填平。毕竟数据库里装的都是真金白银的数据，容不得半点马虎。
