在线页面恢复达到 1000 个限制

Question

我的任务是尝试恢复遭受损坏的数据库（由于 I/O 故障，此后已修复）。我不熟悉数据库或它包含的内容。

我得到了一个旧的（约 3 周）完整备份和一系列事务日志……但是缺少事务日志，所以我只能恢复到某个日期。大约有 2.5 周的数据丢失（并且有大量数据不断添加到此数据库中）。

我还获得了损坏数据库的副本（可以访问，但有很多页面损坏/丢失）。

我已经尝试了典型的DBCC CHECKDB命令（仍然没有repair_allow_data_loss，如果没有其他方法，那将是我的最后手段）。

在多次访问数据库之后（db 是一个 1.5 TB 的小怪物，我所做的一切都很慢并且需要一段时间），我尝试从上次已知的良好备份中对损坏的页面进行在线页面还原。

为此，我编写了一个脚本，该脚本RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'从DBCC CHECKDB输出中创建了许多命令（基本上是一个正则表达式和一个不同的命令）......到目前为止一切顺利，它说我已经达到了 1000 页的限制每个文件（此数据库上有 8 个文件）每个还原命令。

所以它要求我“完成在线恢复”，但我不知道如何做到这一点......我没有尾日志或任何比我开始的完整备份更完整的东西，所以我基本上不知道如何完成恢复以继续尝试其余页面。

我试过一个，RESTORE DATABASE <foo> WITH RECOVERY但也没有用，它要求我提供一个我没有的日志。

有没有人对我如何尝试从这里恢复任何东西有任何提示？或者如何“完成”在线恢复以便我可以继续尝试恢复更多页面？如果我尝试离线还原，我会遇到同样的问题（基本上是添加WITH NORECOVERY到所有内容，然后尝试在最后将其恢复？）

手动处理数据库基本上是可以撤消的……有数百个表有数百万行，并且没有明确的含义。SELECT在几百万行之后，损坏的数据库将在查询中失败，但我不确定我能找出哪里。我试过重建所有非聚集索引，但有行数据损坏的页面，所以这也不起作用。

一些数据丢失是可以接受的，但至少应该尝试实现数据库的一致性。

损坏的数据库仍然在线并且客户端正在处理它（因此它不断获取新数据），因此我在实验室工作台上所做的任何过程都应该在之后在生产数据库上重现（停机对它来说很难）。

这是 SQL Server 2014 企业版

PS：我不是DBA...我是程序员，但是客户尝试了一些“专家”的sql灾难恢复服务，他们已经放弃了，所以我被要求看一下，看看我是否可以做任何事情。

---

更新：经过多次测试，逐页恢复是行不通的，所以我们放弃了这个想法。我们将进行手动恢复（从损坏的表中手动选择丢失的记录并将它们插入到上次已知的良好备份中），为其做一些自动化工具（同样，有成百上千的表）。

Answer 1

标准程序是：

1. 获取需要恢复的页面ID。
2. 使用完整数据库启动页面还原。
3. 应用最新的差异备份。
4. 应用后续日志备份。
5. 创建新的日志备份。
6. 恢复新的 lob 备份。

应用新的日志备份后，页面还原完成，然后页面可用。

示例恢复

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

参考：还原页面 (SQL Server) (Microsoft Docs)参考：RESTORE 语句 (Transact-SQL) (Microsoft Docs)

但是，您的 TLOG 备份中存在漏洞，使用上述过程进行恢复可能会使您的数据库及时恢复到您不希望的状态。

你处于一个复杂的情况。

1. 您的数据库有损坏的页面，并且您的公司不断向有问题的数据库添加新数据。这可能会导致数据库完全停机。难道你想冒这个险？

2. 有人将要承担责任，而您越是尝试修复它，管理层可能就越倾向于最终决定您可能是那个人。难道你想冒这个险？

3. 你扮演了一个你没有被雇佣的角色，让自己陷入困境。您正在努力实现公司 DBA 和外部顾问都无法实现的目标。虽然这似乎是一种高尚的姿态，但您却置自己于危险之中。你可能“暗中承诺”了一些你永远无法实现的事情。难道你想冒这个险？

4. 当有人使用数据库查询损坏的数据时，他们可能会收到一条错误消息。日常工作已经受到影响。您在不可避免的情况下等待的时间越长，生产力受到的影响就越大。难道你想冒这个险？（这个问题也可以向管理层提出）

5. 您公司的备份程序似乎有问题（否则 TLOG 备份怎么会丢失？）并且您仍在运行您的生产数据库，就好像没有问题一样。难道你想冒这个险？

我能给你的最好建议是停止生产并致电微软！或者至少打电话给微软并可能停止生产。

虽然从您的角度来看，我的写作可能看起来过于谨慎且略显夸张，但我个人可以将 DBA 的经历与在类似情况下丢失数据的经历联系起来。我们只丢失了半天的数据，但我们不得不与周围系统重新同步大量数据。

您等待的时间越长，恢复成本就可能越高。

关于页面恢复的限制，这里引用官方文档：

在恢复序列中可以恢复到任何单个文件的最大页数是 1000。但是，如果文件中有多个损坏的页面，请考虑恢复整个文件而不是页面。

^{（强调我的）}

参考：RESTORE 语句 - 参数 (Transact-SQL) (Microsoft Docs)

当一切恢复正常后，DBA 和/或外部顾问可能会考虑为您的数据库实施不同的备份/恢复策略/过程。因为它必须是 7x24，所以你不能冒险备份程序不能为任何情况提供足够的恢复能力。