SQL Server 数据库恢复方法与难点

SQL Server 恢复的章法很清楚：先保现场，再按"有备份/没备份"分两条路走。

第〇步：保护现场

MDF/LDF 所在磁盘先做只读镜像或完整文件拷贝，全程在副本上操作。SQL Server 案例里"修库修出二次损坏"的比例比 Oracle 还高。

有备份：标准还原

RESTORE DATABASE ... WITH NORECOVERY 依次还原全备+差异+日志链，WITH RECOVERY 收尾。日志链完整的能做到分钟级时点恢复——误删表能恢复到出事前那一刻。

无备份：非常规四板斧

1. 日志损坏或丢失、MDF 完好：CREATE DATABASE ... FOR ATTACH_REBUILD_LOG 强行附加，让 SQL Server 给库重造一个空日志——最常见的救法，成功率很高。2. suspect 三板斧：ALTER DATABASE SET EMERGENCY 紧急模式强制开门 → SET SINGLE_USER → DBCC CHECKDB 的 REPAIR_ALLOW_DATA_LOSS 修库 → 修完立刻全库导出重建新库，带病库不长期使用。3. 只有部分表能读：紧急模式下把能读的表 SELECT INTO 逐张抽到新库，坏表单独处理。4. 页级损坏：备份充足时页级还原（PAGE 参数精准回滚单页）；没备份时隔离坏页、抽取周边数据；MDF 内部结构损坏时做文件级手术（十六进制修页头），这是实验室的核心壁垒。勒索病毒加密的，先从备份/影子副本/快照里找未加密版本。

十大难点

日志依赖比表面看起来重得多（重建日志会丢弃未落盘事务，丢多少事前无法评估）；页级校验严格，torn page 修复后内容新旧参半要人工核；REPAIR_ALLOW_DATA_LOSS 是黑箱——丢哪些行跑之前没人知道，必须客户书面确认风险；版本兼容坑（高版本库附加不到低版本，内部版本号 782/852/897 各对应不同版本）；系统库连坐（master 坏了整个实例起不来）；备份意识差（"备份=拷 MDF"，拷的还是运行中的文件）；二次破坏率全数据库领域最高（爱动手、杀毒软件和自动更新在恢复现场持续作案）；TB 级库 CHECKDB 跑几十小时；勒索病毒部分加密（页里一半密文一半明文最难修）；库修好了 ERP（用友/金蝶/管家婆）连不上——业务联调才是验收线。

验证与交付

DBCC CHECKDB 全库零错误、逐表抽查行数、业务系统实际跑起来，客户业务方确认才算数。交付附防复发清单：备份计划、日志别手动删、杀毒白名单、关自动收缩。

一句行话

"repair_allow_data_loss 的 allow data loss 不是说说而已"——这个命令真会丢数据，它是最后手段不是首选。出事后第一动作永远是先备份再修。