小编DB-*_*-GB的帖子

首先，感谢您查看这个 - 我们的生产环境中有一个大型数据库（1.26 TB），其中有几百个损坏的页面并且已经完成了几个月，所以所有的损坏都是一样的可用的备份。

上周晚些时候，我被拖入了这个阶段，因为似乎由于损坏，重新组织索引的预定作业已经失败了一段时间，我们现在处于最大和最常用表上的索引范围在 50% 和80% 的碎片严重降低了应用程序的性能。

我对如何解决这种情况提出了许多想法（相信我，我对替代方案持开放态度），从我读到的内容来看，我认为以下内容听起来是个好主意：

1. 从生产 (SQL Server 2008R2) 中获取损坏数据库的压缩备份，复制到我们的（本地）开发服务器 (SQL Server 2016) 并运行修复（生产系统上没有足够的空间来拥有两个副本损坏的数据库同时附加）。
2. 将此损坏备份的两个副本恢复到我们有足够空间的开发服务器上。
3. 使用这些数据库之一的 allow_data_loss 选项在开发服务器上运行修复，重命名为“DbNameHereRepaired”（我使用 DBCC PAGE 查看的大多数损坏页面似乎都将其数据全部设置为 0x00）。

4. 将其他副本重命名为 DbNameHereCorrupt，尝试使用以下代码运行页面级还原：

       alter database DbNameHereCorrupt set single_user with rollback immediate
   
       --set db to FULL recovery mode
       alter database DbNameHereCorrupt set recovery full
   
       --Declare paths for backups
       declare @fullBackupPath nvarchar(max) = N'D:\Restore\DbNameHereCorrupt-FullBackup.bck'
       declare @tranLogBackupPath nvarchar(max) = N'D:\Restore\DbNameHereCorrupt-LogBackup.bck'
   
       --Take full backup to begin new TLogChain
       backup database DbNameHereCorrupt to disk = @fullBackupPath with init, differential;
   
       --Immediately …

   Run Code Online (Sandbox Code Playgroud)