简介：面向SQL Server数据库管理员与开发人员的实战文档，聚焦SQL Server 2008误删除数据后的紧急恢复问题。内容围绕恢复模式判断展开，说明完全恢复模式下事务日志备份、完全备份还原与STOPAT时间点恢复的基本思路，并区分有完整备份、仅有完全恢复模式、缺少恢复模式三类场景，帮助读者判断何时可用SQL语句处理、何时需借助第三方工具。文档结合Recovery for SQL Server的实际恢复过程，记录选择.mdf数据文件、配置日志检索、生成SQL与bat文件、导入数据等关键环节及注意事项，并提示恢复前应确认备份链完整性与日志连续性，内容兼顾原理说明与工具实操，可作为故障排查与工具选型的参考。包内共1个doc文件，约359KB，篇幅精炼，便于快速查阅。已有1826人学习，适合需要应对误删事故、补充恢复流程认知的数据库从业者在真实故障场景中快速定位可用恢复路径。
1. 误删之后才开始搜索：SQL Server 2008 数据库误删除数据的恢复，难在第一步不在敲命令
SQL Server 2008 数据库误删除数据的恢复，绝大多数人是在 DELETE 语句敲下回车之后才开始搜索的。典型现场是：连接串指错了实例，一条没带 WHERE 的 DELETE 把一个表清空，抬头一看这台实例上没有任何备份作业，只剩一个还在缓慢增长的 .ldf。这时候还能不能救，不取决于你手里有多少工具，而取决于两件更早之前就已经定下来的事——数据库的恢复模式是不是“完全”，以及误删之前有没有一份完整备份。这两件事的状态组合出三种完全不同的结局，走到哪一条路上，后面用的语句、工具、操作顺序都不一样，甚至第 1 章里看着最像“有日志就能恢复”的那句话，也只对了一半。下面按这三种情况拆开讲，先把现象和报错摆清楚，再落到能直接抄的命令和点击顺序。
2. 判场景：恢复模式查错一次，后面所有排查都白做
出事之后先别急着 RESTORE。第一件要做的事是确认这台实例、这个库当前到底处在什么状态，因为它直接决定了你是走三行 T-SQL，还是必须去找第三方工具，还是根本没有可恢复的日志。判断的依据只有两个：恢复模式（Recovery Mode）和备份历史。这两项查错，后面的操作全是无用功，甚至会把仅剩的日志链彻底弄断。
2.1 先确认恢复模式：SIMPLE 下日志被循环截断，删掉的行根本不在里面
很多人的直觉是“SQL Server 不是有事务日志吗，日志里肯定有记录”。日志里确实有记录，但记录能留多久，由恢复模式决定。SIMPLE 模式下，每当 checkpoint 发生，日志中不活跃的部分就会被标记为可复用，VLF 被后来的事务反复覆盖。也就是说，误删发生在几个小时之前，而现在这个库还在正常跑业务，那批 LOP_DELETE_ROWS 记录大概率已经被冲掉了。
查恢复模式和日志状态，一条语句就够：
-- 查恢复模式与日志被谁卡住 SELECT name, recovery_model_desc, -- FULL / BULK_LOGGED / SIMPLE log_reuse_wait_desc, -- 日志为何不能被截断 state_desc FROM sys.databases WHERE name = '你的库名';recovery_model_desc是这一行最关键的值：出现SIMPLE就要立刻改变预期，别再花时间找日志分析工具；出现FULL才有后面两步走。log_reuse_wait_desc正常应该是NOTHING或LOG_BACKUP，如果显示REPLICATION、ACTIVE_TRANSACTION、DATABASE_MIRRORING，说明日志被别的东西卡着，这种情况下日志反而可能还在，是个好消息。
紧接着查备份历史，确认到底有没有可用的完整备份、最近一次是什么时候：
-- 查这个库的备份记录，type: D=完整 I=差异 L=日志 SELECT bs.database_name, bs.type, bs.backup_finish_date, bs.backup_size / 1024 / 1024 AS size_mb, mf.physical_device_name FROM msdb.dbo.backupset AS bs INNER JOIN msdb.dbo.backupmediafamily AS mf ON bs.media_set_id = mf.media_set_id WHERE bs.database_name = '你的库名' ORDER BY bs.backup_finish_date DESC;这里要看的不是“有没有记录”，而是“最近一条D的时间点是不是早于误删时间”。如果最近一条完整备份晚于误删，那根本不需要恢复日志，直接还原那份备份就行；如果最近一条完整备份是三天前的，那就要走完整备份 + 日志链，中间不能断。还要特别注意physical_device_name指向的那个路径今天还在不在，见过太多备份记录写得漂漂亮亮、文件早就被清理脚本删了的情况。
2.2 三种场景对照：你手上缺哪一样，决定了走哪条路
把上面两个查询结果组合起来，只有三种局面。这三种局面的边界必须一次判准，因为走错方向浪费的不只是时间，误删后每多一小时，日志被覆盖的概率就大一分。
| 场景 | 误删前的完整备份 | 恢复模式 | 可恢复性 | 处理手段 |
|---|---|---|---|---|
| 场景一 | 有 | FULL | 高，可精确到秒 | 纯 T-SQL 三步：备份日志、还原完整备份、STOPAT 恢复日志 |
| 场景二 | 没有 | FULL | 中，取决于日志是否完整 | 第三方恢复工具直接解析 .mdf 与 .ldf，导出成 SQL 再回放 |
| 场景三 | 没有 | SIMPLE | 极低 | 事务日志已被截断，只能靠更早的文件级副本、导出文件或人工补录 |
场景一是最舒服的，三条语句搞定，不需要装任何东西，缺点是它对“完整备份存在”这个条件卡得很死。场景二是现实中最常见的，尤其是那些用脚本建库、默认恢复模式、从没配过备份作业的开发库和小型业务库。场景三要坦白说：日志已经被覆盖，靠数据库自身是救不回来的，只能去找有没有更早的 .bak、有没有人手工导过 Excel、有没有从库或报表库还留着旧数据。
注意：判断场景二和场景三的分界线只有一条，就是恢复模式。只要看到
SIMPLE，直接跳到“找更早的数据副本”这条路上，别再尝试日志恢复，也不要相信任何承诺“能从事务日志恢复 SIMPLE 库已删数据”的说法。
2.3 出事后第一件该做的事：别重启、别收缩、别在原库上折腾
确认完场景，接下来最重要的不是技术操作，而是控制住手。误删之后每一次多余的动作都在消耗恢复窗口。
第一，立刻停掉往这个库写入的业务。日志是环形使用的，后续事务越多，早期记录被覆盖得越快。如果实在停不掉，至少把写入量最大的作业先停了。第二，把.mdf和.ldf原样复制一份到另一块盘，复制的副本随便折腾，原文件别碰。第三，不要收缩数据库，不要做 SHRINKFILE，不要在出事的库上直接 RESTORE——RESTORE ... WITH REPLACE会把现有的日志覆盖掉，一旦恢复失败，连做工具分析的材料都没了。第四，不要为了“清干净”而 detach 再 attach，附加过程会改写文件头、可能触发崩溃恢复和日志截断。
如果确实需要做尾日志备份，也要清楚它的副作用。BACKUP LOG ... WITH NORECOVERY会把数据库置为 RESTORING 状态，业务立刻不可用。所以在生产库上执行前，先考虑清楚是否接受这个中断；不接受的话，就在副本上操作，或者退回到场景二用工具处理。
3. 场景一实战：三条 T-SQL 把库拉回误删前那一秒
完整备份在、恢复模式是 FULL，这是唯一能纯用语句解决的情况。顺序不能颠倒：先备份当前尾部日志，再还原完整备份，最后用 STOPAT 把日志滚到误删之前。下面每一步都说清楚它做了什么、参数为什么这么填、失败时看哪条报错。
3.1 第一步：把当前日志尾部备份出来，WITH NORECOVERY 是关键
-- 尾部日志备份：把误删之后到现在的日志一并保存下来 BACKUP LOG [你的库名] TO DISK = N'D:\Recover\YourDb_tail.trn' WITH NORECOVERY, -- 让日志链保持“未完成”，后面才能继续接日志 INIT, -- 覆盖同名文件，避免误追加到旧备份集 STATS = 10; -- 每 10% 打一次进度这一步的意义是把“误删那一刻之后”产生的事务也抓住，形成一条从完整备份到现在的连续日志链。NORECOVERY不是可选项：如果这里写成RECOVERY或者干脆不写，数据库会回到在线状态，日志链在逻辑上被关闭，后面第三步就接不上了。INIT是防止同名文件里堆积多个备份集，还原时选错位置。
如果这一步报“BACKUP LOG 无法备份，因为没有当前数据库备份”或者“日志文件损坏”，说明日志头部已经不可读了，此时可以试WITH NO_TRUNCATE, CONTINUE_AFTER_ERROR——它尝试在数据库受损的情况下仍然把日志读出来，能读出多少算多少。反之，如果报“无法获得对数据库的独占访问”，需要先把连接踢掉：
-- 踢掉占用连接，仅在后一步马上要备份/还原时使用 ALTER DATABASE [你的库名] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; -- 操作完成后记得改回来 ALTER DATABASE [你的库名] SET MULTI_USER;WITH ROLLBACK IMMEDIATE会立刻回滚未提交事务并断开连接，在业务上是有损的，别在业务高峰期随手敲。
3.2 第二步：还原完整备份，REPLACE 与 MOVE 各解决一类报错
-- 先看备份集里的逻辑文件名与物理路径，MOVE 要用到 RESTORE FILELISTONLY FROM DISK = N'D:\Backup\YourDb_full.bak';FILELISTONLY会返回两行，分别是数据文件和日志文件的逻辑名（LogicalName）。记住它们，下一步要按名字搬走。这一步不要省，直接写RESTORE最常见的两个报错都跟它有关。
-- 还原到另一个库名，避免覆盖线上库；文件名要 MOVE 到新路径 RESTORE DATABASE [你的库名_Recover] FROM DISK = N'D:\Backup\YourDb_full.bak' WITH NORECOVERY, -- 还没完，后面还要接日志 REPLACE, -- 目标已存在时强制覆盖 MOVE N'原逻辑数据文件名' TO N'D:\Recover\Recover.mdf', MOVE N'原逻辑日志文件名' TO N'D:\Recover\Recover.ldf', STATS = 10;REPLACE解决的是“备份集包含的数据库备份不同于现有数据库”这类报错，它允许覆盖同名库。MOVE解决的是“无法还原文件……因为文件已存在”的报错——同名库还原时物理路径默认沿用备份时的老路径，老文件还在，自然冲突。把目标库起个带后缀的新名字是血泪经验：恢复到别的名字上，原库还在，验证完再决定是否切过去，中间任何一步出错都能重来。
3.3 第三步：STOPAT 精确到秒，时间点怎么定
-- 把日志滚到误删语句提交之前的时间点 RESTORE LOG [你的库名_Recover] FROM DISK = N'D:\Recover\YourDb_tail.trn' WITH STOPAT = N'2024-06-11T02:17:00', -- 服务器本地时间，早于误删提交时刻 RECOVERY, -- 最后一次恢复，恢复完库可读写 STATS = 10;STOPAT的语义是“恢复到该时间点之前已经提交的事务”，也就是这个时间点之后提交的事务一律不应用。所以取值必须早于误删语句的提交时间，而不是等于或晚于。往前推一到两分钟是安全的，推晚了数据回不来，推早了会有少量正常业务丢失——两害相权，宁可少几个正常事务，也不要让 DELETE 落进恢复范围。时间按数据库服务器的本地时间取，不要按你本机的时区算。
具体时间怎么找？如果开了审计或者业务日志里有记录，直接拿那条时间戳。没有的话，可以用未公开但很常用的fn_dblog看一眼当前日志里最近的删除操作：
-- 查看当前日志中的删除记录，仅对“日志尚未被截断”的库有效 SELECT [Transaction ID], [Begin Time], [End Time], Operation, AllocUnitName FROM fn_dblog(NULL, NULL) WHERE Operation = 'LOP_DELETE_ROWS' ORDER BY [Begin Time] DESC;AllocUnitName会告诉你是哪张表（形如dbo.表名），End Time是事务结束时间，拿它往前减一两分钟做STOPAT就是相当准的取值。前提是这个库的日志还在、没有被截断过，所以这一步要尽早做。
提示：如果
RESTORE LOG报“STOPAT 时间早于数据库的最早可恢复点”，说明完整备份和尾部日志之间断了一段，日志链不连续。这种情况只能以最近一次连续的那段为准，或者退回场景二用工具从文件里捞记录。
3.4 恢复完必须核对的四件事，别急着切应用
库恢复出来只是个开始，直接切过去很可能踩到第二波坑。第一件是自增列（IDENTITY），部分恢复场景下当前值会被重置，插入立刻主键冲突，用DBCC CHECKIDENT('dbo.表名', NORESEED)看当前值，必要时用DBCC CHECKIDENT('dbo.表名', RESEED, 真实最大值)修正。第二件是触发器、外键、索引和权限，库级对象一般在完整备份里，但跨库的对象引用、登录名到数据库用户的映射（SID）可能会断，表现为应用连上去提示“登录失败”或“无权访问”。
第三件是核对数据本身。别只看行数，行数对得上但内容错了更麻烦。挑几张关键表比对最大 ID、更新时间、金额汇总，把结果和业务方确认。第四件是切换方式：新库名和原库名不同，应用的连接串必须改，或者用同义词、别名顶过去，别指望连接串里改了库名就万事大吉，很多 ORM 缓存还留着旧的元数据。
4. 场景二实战：没有完整备份，只能从 .mdf 和 .ldf 里捞记录
没有误删前的完整备份，但恢复模式是 FULL、日志文件还在——这是最难也最有救的一种。思路换了：不再是把备份重放一遍，而是直接解析数据文件和日志文件里的页结构，把标记为已删除的记录重新组织成 INSERT 语句，再灌回一个干净的库。这条路必须靠第三方工具，而工具选型本身就是一道坎。
4.1 选型踩坑：老牌日志分析工具在 2008 上打不开
我最早想到的是几款经典的 SQL Server 日志分析工具，那些在 2000/2005 时代口碑很好的东西。结果是连着翻车两次：第一款导入 .ldf 之后直接提示不支持的数据库版本，界面里连表都列不出来；第二款能连上实例，但解析到一半就报错退出，日志里的行记录一条都没解析出来。
原因不复杂。SQL Server 2008 的日志记录结构和之前的版本有变化，虚拟日志文件内部的组织方式、日志记录头里携带的信息、行内变长列的存储格式都做过调整，早期工具是按旧格式硬编码解析的，遇到新格式要么直接拒绝，要么读出一堆解码失败的乱码。这类工具大多早已停止更新，指望它适配新版本并不现实。
后来试到一款商业恢复套件，明确支持 SQL Server 2008，Demo 版也确实能把已删除的记录找出来并导出——但限制在库文件不超过 24GB。这个限制对中小库够用，对大库就绕不过去。选工具时我总结出三条硬标准：明确列出支持 SQL Server 2008、Demo 版能导出（哪怕只导一部分）而不能只是预览、能同时读取 .mdf 和 .ldf 两份文件。只读 .mdf 的工具在“无备份”场景下基本无解，因为已删除行的原始内容大部分在日志里。
4.2 实操步骤：Custom 模式加“搜索已删除记录”，一步选错全盘白做
工具的操作流程不复杂，但有两处选项一旦选错，跑完一遍什么都拿不到，只能重来。操作前先把.mdf和.ldf复制到本地盘，别直接在网络盘或者生产机的原文件上跑，解析过程会长时间读文件，工具还可能对文件加锁。
| 步骤 | 关键操作 | 作用 | 选错的后果 |
|---|---|---|---|
| 1 | 打开工具，走 File > Recover | 进入恢复向导 | — |
| 2 | 选择数据库数据文件（.mdf） | 让工具识别库结构、表与列定义 | 选错文件版本不匹配，向导直接卡住 |
| 3 | 恢复配置界面选 Custom | 只有自定义模式才允许指定日志并解析已删记录 | 选默认模式只按数据文件扫描，已删除行找不回来 |
| 4 | 恢复选项里勾选“搜索已删除记录”，并指定 .ldf 路径 | 让工具去日志里找 LOP_DELETE_ROWS 对应的行镜像 | 不勾或日志路径错，结果里只有现存行 |
| 5 | 指定目标文件夹 | 存放解析生成的 .sql 脚本与 .bat 批处理 | 路径不可写，Start 之后直接失败 |
| 6 | 点 Start 开始解析 | 生成脚本并弹出数据库创建向导 | — |
| 7 | 在向导里选择目标数据库 | 决定脚本回放到哪个库 | 选到生产库上，会往里插重复数据 |
| 8 | 选择同时导入数据文件与日志文件中的可用数据 | 合并两份来源，覆盖更全 | 只选数据文件，删除记录缺失 |
第 3 步和第 4 步是整条流程的关键，值得单独强调：Custom 决定“能不能看日志”，搜索已删除记录决定“看不看已删的行”，两者缺一，跑完只能得到一份和现状完全一致的副本，等于白做。第 8 步的选项名称各家措辞不同，但意思都是“同时从数据文件和日志文件中导入可用数据”，日志文件是已删记录的主要来源，漏选就前功尽弃。
4.3 生成的 SQL 和 bat 别直接往生产库上灌
解析完成后，目标文件夹里会出现两类东西：一堆.sql文件，里面是按表组织的 INSERT 语句；以及.bat批处理，用来批量调用命令行工具把这些脚本灌进库。这里有个很容易忽略的点——脚本里可能包含整库所有表的数据，而且顺序是按工具内部逻辑排的，外键约束没被考虑进去。
稳妥的做法是新建一个空库当回放目标，先把脚本按依赖关系排一下，父表在前、子表在后，或者干脆在回放前把外键禁用。执行可以借助sqlcmd，一条一条来，失败就停：
# 逐条回放工具生成的 SQL，-b 让出错时返回非零退出码 sqlcmd -S "127.0.0.1,1433" -U sa -P "你的密码" \ -d RecoverDb \ -i "D:\Recover\out\recover_001.sql" \ -b -o "D:\Recover\out\recover_001.log"-S指定实例地址，带端口时用逗号分隔；-d是目标库，一定是刚建的空库；-i是输入脚本；-b让sqlcmd在遇到错误时中止并返回非零退出码，不加这个参数出错也会继续往下跑，最后你分不清哪些表没进去；-o把输出写到日志文件，几百条 INSERT 刷屏根本看不过来。跑完先别急着高兴，用行数和关键字段抽样比对，尤其是那些有唯一索引的表，重复插入会直接报冲突，看到冲突就说明这份脚本里既有现存行也有已删行，需要过滤。
4.4 24GB 这个上限怎么绕
商业工具的 Demo 版限制库文件大小，超过就不给导出。绕的思路不是破解，而是把“要分析的文件”变小，或者把“要恢复的范围”变小。
第一种做法是只复制需要恢复的那部分内容。如果误删只涉及两张表，可以把整个库的备份还原到一个测试实例上，再从测试实例里摘出这两张表的数据文件和日志文件，文件体积会小很多。第二种做法是先做一次文件级压缩再解压到临时目录，减小传输和处理时的开销，但对工具识别的文件大小限值没有帮助，只能改善 IO。第三种做法是分批：先按表导出，工具若支持选择表就只勾选相关表，导出的脚本量也会小很多，回放和校验都更容易控制。
还有一种情况值得提一句：如果日志文件本身已经很大（比如几十 GB），而误删发生的时刻在很靠前的位置，解析会非常慢。这时候先确认误删的大致时间，再决定是否值得跑。工具解析是按日志顺序扫的，时间越靠后越快出结果。
5. 避坑：这五件事做错一次，数据就真回不来了
下面这几条都是实际踩过或者见别人踩过的，按“现象 → 原因 → 解决”记，遇到时对着看。
5.1 现象：STOPAT 恢复完，数据是回来了，但比误删前少了几个小时
原因是STOPAT的时间取值偏早。有人习惯“保险起见往前推半小时”，结果把误删之前几小时的正常业务一并丢掉了，而这几小时的数据往往比误删的那批更重要。
解决：时间点要卡在误删语句提交前的一到两分钟，不要贪多。取值依据优先用业务日志、审计表里的时间戳；没有就用fn_dblog里的LOP_DELETE_ROWS记录的End Time。恢复前先在测试实例上跑一遍STOPAT，确认目标表数据量对得上，再决定正式恢复用哪个时间。
5.2 现象：执行BACKUP LOG报“无法备份日志，因为没有当前数据库备份”
原因是日志链断了。完整恢复模式下,日志备份必须建立在一次完整备份的基础之上，从来没做过完整备份的库，日志备份会被拒绝，即使日志文件里其实有数据。
解决：先做一次完整备份（BACKUP DATABASE ... WITH COPY_ONLY避免打断现有备份链），再备份日志。但要注意，这时候补做的日志备份只覆盖“从现在开始”的日志，误删那段是否还在取决于日志有没有被覆盖过。所以这个报错出现时，先别急着重做备份，先确认当前日志里还能不能看到LOP_DELETE_ROWS，看不到就直接转场景二。
5.3 现象：恢复出来的表插入数据就报主键冲突，明明表是空的
原因是自增列的当前值没有跟着数据一起恢复。某些恢复路径下 IDENTITY 的种子值停留在初始状态，插入时从 1 开始分配，和恢复进来的历史 ID 撞车。
解决：用DBCC CHECKIDENT('dbo.表名', NORESEED)查当前值，用SELECT MAX(主键列) FROM dbo.表名查真实最大值，再用DBCC CHECKIDENT('dbo.表名', RESEED, 真实最大值)对齐。多张表都要做，别只修报错那一张。顺带检查所有有唯一索引、唯一约束的列，恢复过程中这些约束可能没被校验过，留着隐患。
5.4 现象：第三方工具里能看到已删除的行，导出时提示超限或者导出来是 0 行
原因有两个方向。一是数据库文件超过了 Demo 版的限制，预览阶段不校验大小，导出阶段才检查，所以会出现“看得见导不出”。二是恢复配置里选了默认模式而不是 Custom，或者没勾“搜索已删除记录”，工具只按数据文件扫了一遍现存行。
解决：先核对文件大小是否在限制以内，超了就按 4.4 的办法把范围缩小。再回到配置界面确认 Custom 和“搜索已删除记录”两个选项都选了、.ldf路径指向的是误删时刻前后还在使用的那个日志文件。如果两个都对还是 0 行，多半是日志已经被截断过，删除记录被覆盖了，这种情况只能承认失败。
5.5 现象：为了“干净”把库 detach 再 attach，之后日志文件变小了、记录也没了
原因很隐蔽。附加数据库时 SQL Server 会做一次崩溃恢复和日志一致性检查，在不满足日志链条件的情况下可能触发日志截断；同时附加过程会改写文件头里的信息，一些第三方工具依赖文件头判断状态，附加过之后解析出来的结果会异常。
解决：出事后第一原则就是不动原文件。需要分析就把.mdf和.ldf复制一份到别的盘，在副本上折腾。已经 detach 的，用CREATE DATABASE ... FOR ATTACH挂回去，但别指望日志还是原样。这条坑最贵的地方在于它是不可逆的，事后没有任何补救手段。
注意：以上五条里，5.5 是唯一会造成不可逆损失的。恢复过程中凡是涉及“移动、附加、收缩、重建”的操作，一律先在副本上验证。
6. 快速定位：五分钟判断这个库还能不能救
真出事了，需要的不是一堆原理，而是一个能在五分钟内给出结论的判断顺序。顺序错了，你会在错误的方向上花掉恢复窗口。我一般的顺序是：先看恢复模式，再看备份历史，再看日志还在不在，最后才决定用工具。
| 顺序 | 查什么 | 怎么查 | 结论 |
|---|---|---|---|
| 1 | 恢复模式 | sys.databases.recovery_model_desc | FULL 才有日志恢复的可能；SIMPLE 直接转找旧副本 |
| 2 | 备份历史 | msdb.dbo.backupset按时间倒排 | 有误删前的 D 类型备份 → 走场景一 |
| 3 | 日志是否完整 | fn_dblog里是否有LOP_DELETE_ROWS | 有 → 日志可用；没有 → 只能靠文件解析 |
| 4 | 删除时间点 | 业务日志 /fn_dblog的End Time | 用来定 STOPAT 取值 |
| 5 | 文件副本 | .mdf/.ldf复制到独立盘 | 后续所有操作都在副本上做 |
第三步和第四步是最容易被跳过、也最影响成败的两步。很多人拿到“恢复模式是 FULL”这个结论就直接开干，结果 STOPAT 时间拍脑袋定，恢复完发现少了半天数据。
验证是否真的恢复到位，别只看“表里有数据了”。挑三样东西核对：一张表的行数与最大 ID 是否与业务方给的基线一致、几张关键表的最新更新时间是否停在误删前、以及应用侧能不能正常跑一次写操作（这一步能顺带暴露自增列、触发器、权限的问题）。这三项都过，才算真的恢复完。
还有一条我现在的习惯：不管库多小，建库的第一条语句一定是把恢复模式设成 FULL，并且当天就把完整备份和日志备份的作业挂上、再跑一次还原演练。不是我勤快，是被“没有备份的库恢复模式还是 SIMPLE”这种情况坑过一次，那种明明数据就在磁盘上、却因为日志被循环覆盖而一点办法都没有的感觉，比任何报错都难受。上面这套判断流程和操作步骤，连同工具的具体点击顺序，都整理在了这份实操记录里，照着走一遍，至少下次接到电话时不会先愣两分钟。希望帮到你。
本文还有配套的精品资源，点击获取
