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

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

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

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

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

在许多数据库进入数据库之后（数据库是一个1.5 TB的小怪物，我所做的一切都很缓慢并且需要一段时间），我尝试从上次已知的损坏页面备份中恢复联机页面。

为此，我已经完成了一个脚本，该脚本RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'从DBCC CHECKDB输出中创建了许多命令（基本上是一个正则表达式和一个单独的命令）...到目前为止，效果很好，可以说达到了1000页的限制每个还原命令每个文件（此db上有8个文件）。

因此，它要求我“完成在线还原”，但是我对如何做到这一点感到茫然。我基本上不知道如何完成还原以继续尝试其余页面。

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

有人对我如何从此处恢复任何内容有任何提示吗？还是如何“完成”在线还原，以便我可以继续尝试恢复更多页面？如果我尝试脱机还原（基本上添加WITH NORECOVERY到所有内容，然后尝试将其恢复到最后，是否会遇到相同的问题？）

手工计算数据库基本上是不可能的……有数百个表和数百万行，并且没有明确的含义。数SELECT百万行后，损坏的数据库将对查询失败，但是我不确定我可以算出哪里。我试过重建所有非聚集索引，但是有行数据损坏的页面，所以也行不通。

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

损坏的数据库仍处于联机状态，并且客户正在使用它（因此它将不断获取新数据），因此，我在实验室工作台上执行的任何过程都应可在生产数据库上重现（停机将非常困难）。

这是SQL Server 2014 Enterprise

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

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

标准程序是：

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备份？），并且您仍在运行生产数据库，就好像没有问题一样。难道你想冒这个险？

我能给您的最佳建议是停止生产并致电Microsoft！或者至少致电Microsoft，并可能停止生产。

从您的角度看，我的写作似乎过于谨慎和戏剧化，但我个人可以将DBA的经历与类似情况下的数据丢失联系起来。我们只丢失了半天的数据，但是我们不得不将许多数据与周围的系统重新同步。

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

至于页面还原的限制，请参考官方文档中的报价：

还原序列中可以还原到任何单个文件的最大页面数为1000。但是，如果文件中损坏的页面数量很少，请考虑还原整个文件而不是页面。

^{（重点是我的）}

参考：RESTORE语句-参数（Transact-SQL）（Microsoft Docs）

当一切恢复正常后，DBA和/或外部顾问可能希望考虑为数据库实施不同的备份/还原策略/过程。由于必须达到7x24的速度，因此您可以冒险使用无法针对任何情况提供足够的还原功能的备份过程。

我看到您尝试了不同的方法，包括使用数据恢复“专家”来修复此损坏的数据库，尤其是大小超过1 TB的数据库。这使过程变得更加困难，并且与时间赛跑。作为一名经验丰富的DBA，我在大多数情况下都遇到过类似的情况，这些情况下都有可以还原的良好备份。在继承错误的备份和损坏的数据库的情况下，我在很大程度上依赖于称为Stellar Phoenix SQL数据库修复工具的第三方工具。该工具以修复损坏的数据库（.mdf和.ndf）而闻名。以下是该工具的一些功能：

• 修复损坏的SQL数据库（.mdf＆.ndf）文件
• 恢复表，触发器，索引，键，规则和存储过程

• 从SQL数据库执行已删除记录的恢复

• 保存数据库的扫描结果以在以后执行恢复

• 允许以MSSQL，HTML，XLS和CSV格式保存修复的文件
• 支持MS SQL Server 2016、2014、2012、2008和更早版本

该工具要求.mdf和.ndf文件处于脱机状态，因此，如果您拥有损坏的PROD数据库的副本，而不必停止SQL Server服务，则该工具非常有用。

最好的部分是试用版为您提供了该工具的全部功能，但无法导出/保存已修复的数据库。您仍将能够查看所有恢复的数据库对象以及详细的修复日志文件，其中提供了有关修复过程不同阶段的详细信息。

随时下载并查看是否有帮助。在这里下载

我还写了一篇关于该工具在此站点上如何工作的博客：samosql博客

感谢您和HTH使您成为当下的英雄！

PS。当这场风暴结束后，请记住告诉管理层，尤其是对于这样的数据库，需要对其备份过程进行大修。重复这种情况是完全不能接受的！:)