这事儿我见得多。前几天一个朋友半夜打电话来，声音都有点颤抖，跟我说手一抖把生产库删了。我安慰他说别慌，SQLServer只要不是把硬盘物理删掉，数据大概率还能捞回来。他半信半疑，我隔着电话一步步指点，半小时后数据全回来了。其实误删数据库恢复的核心就三步，只要记住，真遇上也不至于手足无措。
第一步，立刻停止对该库的所有写入操作。很多人一发现删库，第一反应就是赶紧重建同名库，想把数据灌进去，这是一大忌。SQLServer在执行删除时，数据文件并不会立刻从磁盘消失，系统只是把数据库标记为“已删除”，文件仍然保留在原位置。只要不再往磁盘写入新数据，这些文件就有机会被找回。因此，一旦发现误删，立刻通知相关人员停止所有写操作，包括不要生成新的日志或备份文件。做好这一步，后面的两步才有意义。
第二步，检查事务日志，看是否有完整备份。SQLServer的事务日志记录了每一次数据变更。如果数据库开启了完整恢复模式，日志里可能仍保留删除前的状态。此时可以在另一实例上创建同名数据库，使用 STOPAT 选项把日志恢复到删除前的时间点。具体做法是先用 BACKUP LOG 备份当前日志，然后执行 RESTORE DATABASE 并加上 STOPAT 参数。如果运气好，甚至可以精确到秒级恢复。当然，如果数据库使用的是简单恢复模式，日志中就没有历史记录，只能转向第三步。
第三步，使用第三方工具扫描磁盘，找回数据文件。如果前两步未能成功，仍有一线希望。SQLServer删除数据库后，MDF 与 LDF 文件仍在磁盘，只是被操作系统标记为可用空间。此时可以使用 ApexSQL Recover、Stellar Phoenix 等数据恢复工具，它们能够扫描磁盘，定位被标记删除但尚未被覆盖的数据库文件。这类工具通常提供预览功能，恢复前可以先确认数据是否完整。操作也很简单：指定扫描路径，工具会自动识别 SQLServer 的数据页并导出为 BAK 文件，随后在另一实例上恢复即可。成功率取决于删库后写入磁盘的次数，写得越少，恢复概率越高。
不过，防患于未然永远比亡羊补牢省心。我的那位朋友事后跟我说，他一直觉得备份是 DBA 的事，自己只负责开发，没必要管。结果一次误删差点把整个项目弄砸。其实 SQLServer 的备份机制很简单，只要在维护计划里设置每日全备、每半小时日志备份，即使误删，最多也只会损失半小时的数据。而且现在很多云 SQLServer 已经自带“时间点恢复”功能，选取删除前的时间点，点一下就能恢复。这些设置花不了十分钟，却能省掉半夜打电话的尴尬。
还有一个细节很多人不知道：SQLServer 的“删除数据库”操作在某些情况下是可以回滚的。如果删除时勾选了“关闭现有连接”和“删除备份和历史记录”，数据库会被立即彻底删除，无法回滚。但如果只是右键点击删除而没有勾选这些选项，系统会弹出确认框，这时点“取消”即可。很多误删都是因为手快点了确认，没注意选项。所以下次删库前，先深呼吸三秒，确认对话框里有没有“恢复旧版本”的提示。SQLServer 2016 以上版本，系统数据库 master 中保存了所有数据库的元数据，如果只是误删了用户库，而 master 里仍有记录，配合 DBCC 命令可以把元数据恢复，数据文件仍在时即可重新附加。
说个真实案例。有位运维同事半夜加班，想删一个测试库，手一滑点到了生产库。冷汗瞬间冒了出来，但他没有慌，立刻停掉所有应用服务，检查备份策略，发现库是完整恢复模式，日志保留了两周。他用了 STOPAT 命令把数据库恢复到删除前五分钟的状态，数据一点没丢。第二天老板问他为什么凌晨两点数据库会重启，他淡定地说：“我在做性能优化。”只要懂方法，事故完全可以变成故事。
所以记住这三步：停写入、查日志、扫磁盘。SQLServer 误删数据库并没有想象中那么可怕，可怕的是你啥都不会就盲目操作。备份永远是第一道防线，即使没有备份，也不要轻易放弃。只要数据没有被覆盖，就还有恢复的可能。下次有人说删库只能跑路，就把这篇文章甩给他吧。
