干这行的人都知道，数据库这东西，平时安安静静的，一旦出问题就是大事。硬盘坏了、服务器断电、误删了表，哪一样都能让人瞬间冒冷汗。我见过太多人，平时不备份，真到要恢复的时候才急得团团转。SQL2012虽然是个老版本，但用的人依然不少，它的还原机制跟后来的版本大差不差，把这套流程吃透，换到别的版本也能触类旁通。今天不整那些虚的，直接上实操，把还原数据库这事拆成三步，每一步该干什么、注意什么，全给你摆明白。
第一步，准备工作没做好，后面全是坑。你别一上来就点还原，先确认两件事：备份文件是哪儿来的，目标数据库要覆盖成什么样。很多人备份文件跟日志混在一起，或者备份文件日期对不上，还原到一半才发现文件损坏，那就麻烦了。我建议你先把备份文件拷到本地磁盘，路径别带中文和空格，比如D:ackup，这样最稳妥。然后打开SQL Server Management Studio，连上实例，右键“数据库”，选“还原数据库”。这时候它会弹出一个窗口，你选“源设备”，点那个省略号按钮去定位备份文件。这里有个关键点，如果目标数据库已经存在，且你确定要用备份覆盖它，记得在“选项”页里勾上“覆盖现有数据库”，不然它会报错说数据库正在使用。还有，很多人忽略“恢复状态”这个下拉框，默认是“RESTORE WITH RECOVERY”，意思是还原完成后数据库直接可用，但如果你还想继续还原日志，就得选“RESTORE WITH NORECOVERY”。新手最容易卡在这儿，记好了。
第二步，选对备份类型，别一股脑全还原。SQL2012支持完整备份、差异备份和日志备份，三种备份的还原顺序是有讲究的。如果你只有一个完整备份文件，那简单，直接选它还原就行。但如果你有完整备份加好几个差异备份，或者中间还有日志备份，那顺序就乱了套。正确做法是：先还原最新的完整备份，再还原一次完整备份之后的那个最新差异备份，按时间顺序还原所有日志备份。举个例子，你周一做了完整备份，周二做了差异备份，周三每小时记一次日志。周四早上数据库挂了，你要恢复，那就先还原周一那份，再还原周二那份差异，然后把周三的日志一个接一个还原上去。这一步很多人偷懒，直接挑个最新的备份文件就还原，结果数据丢了半天，那还不如不还原。还有一个细节，还原时如果提示“LSN”相关错误，说明你备份链断了，要么缺了某个日志文件，要么选错了差异备份，回头检查一下文件清单。
第三步，验证还原结果，别以为弹出“已成功还原”就万事大吉。这个坑我踩过，也看别人踩过无数次。SQL2012的还原操作，只要语法对、文件没损坏，它就会显示成功。但成功还原不代表数据是对的，尤其是当你把数据库还原到另一个服务器，或者覆盖了生产库，一定要做完整性检查。最直接的方法，跑一句DBCC CHECKDB，看看有没有一致性错误。或者简单点，打开几个关键表，查一下最新记录的时间戳，看看数据是不是你预期的那天。还有，如果还原后应用连不上数据库，多半是登录名映射问题。备份文件里存的是原服务器的登录SID，新服务器上没有对应的登录，或者SID对不上，就会导致权限验证失败。解决方法是在目标库上执行spchangeuserslogin，或者手动把登录名重新映射一遍。这个坑特别隐蔽，搞不好你以为数据坏了，其实只是权限没跟上。
说完了三步，再聊几个实战里的高频问题。第一个，数据库还在“正在还原”状态，卡住不动。这多半是你用了NORECOVERY选项，还原完没有接着执行RECOVERY。解决方法是执行RESTORE DATABASE 库名 WITH RECOVERY，一行命令就能把它拉起来。第二个，还原时报“无法获得独占访问权”，这是因为目标库还有连接在占用。你可以把数据库设为单用户模式，或者直接杀掉那些进程。SQL2012里右键数据库，任务，分离，或者用ALTER DATABASE SET SINGLEUSER WITH ROLLBACK IMMEDIATE，都能解决。第三个，备份文件是从老版本SQL Server导出的，比如SQL2008的备份，拿到SQL2012上还原，一般没问题，反过来就不行。低版本不能还原高版本的备份文件，这是硬性规定，认栽就好。
还有一点，别把还原当成事后补救的万灵药。我见过不少团队，备份策略稀烂，一周才做一次完整备份，中间数据丢了就只能靠日志。但日志文件如果被截断过，或者日志备份不连续，那基本就凉了。SQL2012的默认恢复模式是“简单”，这种模式下日志会被自动截断，你根本没法做时间点恢复。所以，如果业务要求数据不能丢超过几分钟，一定要把恢复模式改成“完整”，并且定期做日志备份。这个改动很小，但关键时刻能救命。另外，备份文件别跟数据库放在同一块硬盘上，这道理谁都懂，但真出事的时候，往往是硬盘整个挂了，备份跟数据一起陪葬，那才叫欲哭无泪。
写到这里，我想到一个真实案例。有个朋友的公司，财务系统跑在SQL2012上，某天运维手滑，把一个表给DROP了。备份倒是天天做，但那是凌晨2点的完整备份，当天白天的数据全没了。他们急得找我，我一看，恢复模式是“简单”，日志根本没得救。只能把昨天的备份还原，再手动补录白天的单据，折腾了一下午。这事要是当初把恢复模式改成“完整”，定期备份日志，最多丢几分钟的数据。所以，还原技术只是一环，前期的备份策略才是真正的防线。
回到题目本身，SQL2012数据库还原，说白了就是这么三步：准备文件、按顺序还原、验证结果。操作本身不复杂，复杂的是你面对的环境——文件缺失、权限错乱、连接占用、备份链断裂，每个坑都得踩一遍才长记性。但只要你把这三步刻在脑子里，遇到问题先理清备份链，再动手，就稳了。毕竟数据这东西，丢一次，可能连饭碗都保不住。
