这事儿得从上周一个朋友半夜打来的电话说起。他那边急得跟热锅上的蚂蚁似的，称公司服务器硬盘坏了，SQL Server 2008里的几个核心数据库全挂了，备份文件虽然还在，但恢复过程卡得让人崩溃。我一边安慰他别慌，一边脑子里飞快地过了一遍SQL Server 2008恢复数据库的常规操作。说实话，这版本虽然老，但很多企业仍在使用，尤其是一些中小公司，升级成本高、业务系统又依赖，碰到数据恢复这事，真能让人一夜白头。好在只要备份文件没丢，路子还是有的，关键看你走对没。
恢复数据库的第一步永远是弄清楚手里有什么“牌”。SQL Server 2008的恢复模式主要分三种：完整恢复模式、完整日志恢复模式和简单恢复模式。很多人一上来就想着“点几下鼠标就完事”，结果选错模式，恢复出来的数据要么残缺不全，要么时间点对不上。比如在简单模式下，你只能恢复到最近一次完整备份的时间点，中间的变化全没了。完整模式虽然能还原到任意时间点，但日志文件会不断增长，管理不当反而把自己坑了。所以动手前先打开SQL Server Management Studio，右键数据库，查看“属性”里的恢复模式，再衡量手里的备份链——完整备份、差异备份、事务日志备份，这些文件缺一不可，像拼图一样，少一块就拼不全。
接下来就是实际操作了。最常见的情况是，你有一份完整备份文件，想把它恢复到新服务器或原服务器的另一个实例上。这时，SQL Server Management Studio里的“还原数据库”功能是最直观的入口。但别急着点“确定”，有个关键步骤容易忽略：在“选项”页面里一定要勾选“覆盖现有数据库”，否则系统会报错说“数据库正在使用”。另外，“恢复状态”要选“RESTORE WITH RECOVERY”，这样才能让数据库正常上线。我曾见过同事图省事选了“RESTORE WITH NORECOVERY”，结果数据库一直处于“正在还原”状态，用户连不上，他还纳闷了半天。说白了，这点小细节就是专业和业余的分水岭。
如果手里只有完整备份，恢复确实简单，但现实往往更残酷。很多公司只做完整备份，觉得省事，结果数据库被误删了一张表或某个存储过程出问题，你总不能把整个库回滚到几天前吧？这时差异备份和日志备份就派上用场。比如周日上午做了完整备份，周一凌晨做了差异备份，周一上午10点又做了日志备份，随后中午12点出事。你可以先还原周日的完整备份，再还原周一的差异备份，最后还原10点的日志备份，这样数据就能回到10点的状态。中间损失的两个小时虽然有点肉疼，但总比回到三天前强。SQL Server 2008的日志备份支持“STOPAT”参数，精确到秒，例如 ，可以直接恢复到出问题前的那一刻。
恢复过程中最让人头疼的，莫过于“孤立用户”。所谓孤立用户，就是把数据库恢复到新服务器后，数据库里的用户名和登录名对不上。比如原服务器上有个用户叫“张三”，登录名也是“张三”，但新服务器上可能没有这个登录名，或者SID（安全标识符）不一致。这时，用“张三”登录会报错“无法打开数据库”。解决办法其实很简单，一条SQL语句就能搞定：。很多人不知道这条命令，或者忘了在恢复后执行，结果花半天排查网络、权限，最后才发现是孤立用户。记住，恢复完数据库后，第一件事就是检查用户映射，别让孤立用户卡住你的脖子。
说到性能，SQL Server 2008的恢复操作相当吃资源，尤其是数据量大的库。我曾帮一个客户恢复一个200 GB的数据库，完整备份花了40分钟，恢复过程更慢，磁盘I/O直接飙到100%。后来我学乖了，恢复前先检查目标服务器的磁盘空间和CPU负载，避开业务高峰期，最好半夜进行。另外，如果备份文件是压缩的（SQL Server 2008 R2开始支持压缩），恢复时解压会消耗CPU，但能节省传输时间。权衡之下，我一般建议把备份文件放在本地磁盘，别放在网络共享上，否则网络延迟会把人急死。曾有一次我直接从NAS恢复，速度慢得像蜗牛爬，后来把文件拷贝到本地，速度翻了三倍。
如果连备份文件都没有，或者备份文件损坏，那就真的叫“叫天天不应”。SQL Server 2008没有像高版本那样内置的“恢复向导”来从损坏的备份中扒数据，这时只能靠第三方工具。市面上有些软件声称能修复MDF文件，但价格不菲，成功率也不一定。我见过最惨的案例：一个客户为了省备份空间，把事务日志备份设成每30分钟一次，但完整备份一个月才做一次。结果日志文件因磁盘故障损坏，完整备份又太旧，恢复出来的数据只有一个月前的，期间的几十万条交易记录全没了。老板气得拍桌子，DBA直接卷铺盖走人。这件事告诉我们，备份策略不能省，尤其是SQL Server 2008这种老版本，容错能力本就不如新版，备份频率和完整性是保命符。
所以，我想说的是，恢复数据库固然需要技术操作，更关键的是平时的备份习惯和预案。SQL Server 2008虽然老，但只要备份文件在、恢复步骤对，数据就不会丢。我那位朋友按我建议操作，花了三个小时把数据库恢复到出问题前15分钟的状态，虽然损失了几条记录，但总算没伤筋动骨。他感慨，以前总觉得备份是IT部门的杂活，现在才明白那是救命稻草。这话虽土，却很有道理。每一个DBA都应该把“恢复演练”当成日常工作，而不是等到出事了才临时抱佛脚。毕竟，数据是企业的命，恢复数据的能力才是我们真正的底气。
