数据库还原卡在0%，这问题我见过太多次了。不管是开发环境还是生产环境，运维群里一有人截图“还原进度0%”，后面必跟一串问号。今天就把我踩过的坑、试过的招儿全摊开聊，从最基础的到最刁钻的，按排查顺序给你捋一遍。
先说个最常见的坑：你点了还原，界面显示0%，然后就没动静了。这时候90%的人第一反应是等，或者狂点取消。其实先别急，打开SQL Server Management Studio的“活动监视器”，看一眼“进程”列表里有没有那个还原会话。如果有，看它的“等待类型”——如果是LCKMX，说明有别的进程占着数据库没撒手；如果是ASYNCNETWORKIO，那是客户端网络慢，数据传不过来。这两种情况，解决方案完全不同。前者要找到阻塞源，后者要检查网络和防火墙。
再说个容易忽略的：备份文件本身有问题。比如你从别的服务器拷来的.bak文件，传输过程中损坏了，或者那个备份本身就不完整。怎么验证？用RESTORE VERIFYONLY FROM DISK='路径文件名.bak'，这条命令会检查备份文件的完整性，但不执行还原。如果它报错，那问题就清楚了——文件坏了，要么重新备份，要么重新传输。还有个细节，跨平台传输备份文件，比如从Linux服务器拷到Windows，记得检查文件大小是否一致，有时候FTP传一半断了，你以为传完了，实际文件不完整。
接下来聊个高级的：还原过程中卡住，可能是因为数据库日志文件太大，或者数据文件与日志文件不在同一磁盘，而日志盘满了。这时候你去看SQL Server的错误日志（默认在安装目录下的MSSQLLog文件夹），会看到类似“Log file 'xxx' is full”或者“Disk space exhausted”的提示。解决办法不是删日志，因为还原过程中日志是回滚用的，删了更麻烦。正确做法是给日志盘腾空间，或者把数据文件和日志文件放到不同磁盘，然后重新还原。
还有一个经常被忽略的坑：目标数据库已经有同名文件但路径不对。比如你原来数据库文件在D盘，现在新服务器只有C盘，你直接选还原，系统找不到原路径就会卡住。这时候要在还原界面的“选项”里，勾选“覆盖现有数据库”，然后手动把数据文件和日志文件的路径改成新服务器上存在的路径。这事我遇到过好多次，尤其是从旧服务器迁移到新服务器时，路径不一致导致还原卡在0%，一查原因就是路径问题。
再说个跟权限相关的。SQL Server服务账户如果对备份文件所在目录没有读权限，还原也会卡住，而且经常是0%不动。怎么验证？用服务账户登录系统，手动去打开那个.bak文件，看能不能读取。如果不能，就把备份文件放到SQL Server默认备份目录下（通常是C:Program FilesMicrosoft SQL ServerMSSQLxx.MSSQLSERVERMSSQLBackup），或者给服务账户授予读取权限。这个坑特别隐蔽，因为你用SSMS登录时用的是自己的Windows账户，能访问文件，但SQL Server服务用的却是另一个账户。
还有个终极杀手锏，适用于前面所有方法都试过但依然卡住的情况：用T-SQL脚本执行还原，而不是用图形界面。脚本如下：
RESTORE DATABASE 你的库名 FROM DISK = 'D:备份文件.bak' WITH MOVE '逻辑文件名' TO 'D:数据文件.mdf', MOVE '日志逻辑文件名' TO 'D:日志文件.ldf', STATS = 5, REPLACE
其中STATS = 5表示每完成5%显示一次进度，这样你能实时看到还原到底在动还是真卡死了。逻辑文件名怎么查？用RESTORE FILELISTONLY FROM DISK='路径备份文件.bak'，会列出备份内的所有逻辑文件名。用脚本的好处是，你能看到具体的百分比进度，如果卡在某个百分比不动，说明问题出在那个文件上，针对性排查更快。
说个玄学但真实存在的：杀毒软件拦截。有些企业版杀毒软件会实时扫描文件操作，SQL Server还原大文件时，杀毒软件扫描会占用大量IO资源，导致还原速度极慢，看起来像卡住。解决办法是暂时关闭杀毒软件，或者在杀毒软件中添加SQL Server数据目录和备份目录的排除项。这问题我帮一个客户排查过，他们还原一个200GB的数据库，卡了三个小时不动，关了杀毒软件后，十五分钟就完成了。
还有个思路值得提，如果你确认备份文件没问题、权限没问题、路径没问题，但还原就是卡0%，可以检查一下SQL Server是否安装了最新的Service Pack和累积更新。有些版本的SQL Server存在已知的还原bug，微软在后续补丁中修复了。比如SQL Server 2016 SP2之前，有个bug会导致从网络共享路径还原时卡死。升级补丁前，先用脚本方式还原，至少能知道是环境问题还是软件问题。
写到这儿，心里有数了。还原卡0%这事儿，多数情况不是SQL Server本身坏了，而是环境因素——网络、权限、路径、磁盘、占用。按我上面说的顺序，先看活动监视器，再验备份文件，然后查路径权限，用脚本兜底。记住一个原则：别在图形界面里干等，主动去查进程、查日志、查磁盘。如果你现在正卡在0%，先别慌，打开活动监视器看一眼等待类型，八成就能定位问题。要是还不行，把SQL Server错误日志几十行贴出来，基本就能找到答案了。
