在小的停机时间窗口中修复损坏的日志文件

Question

我正在与一位客户合作，该客户从其 SharePoint 数据库之一的日志备份中收到以下错误：

Backup detected log corruption in database FOOPORTAL_SP2010_Config. Context is FirstSector. 
  LogFile: 2 'D:\MSSQL2K8\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FOOPORTAL_SP2010_Config_log.LDF' 
  VLF SeqNo: x864 VLFBase: x172d0000 LogBlockOffset: x176b1800 
  SectorStatus: 2 LogBlock.StartLsn.SeqNo: x771 LogBlock.StartLsn.Blk: x1f0c 
  Size: x400 PrevSize: x200

我知道这表明磁盘硬件和/或 IO 子系统存在问题，我们一直在与托管提供商合作。具体来说，这似乎是 /a 磁盘上的一个“坏点”，因为该数据库的日志文件一直报告它，但过去几周其他 6 个数据库日志备份没有报告其他错误，也不适用于 20 多个其他数据库的完整数据备份中的任何一个。

我的直接问题是客户端已经以这种方式运行了几个星期，因为这是一项强制要求的 24x7 服务，他们一直无法给我一个停机服务窗口来解决这个问题，直到今晚（突然）2 小时. 不幸的是，数据库损坏和这种管理工作不是我在 SQL Server 中的专长，我不确定最好/最安全/最可靠的方法是什么。

我现在的初步计划是：

1. 停机窗口一开始就对数据库进行完整备份（完整备份一直在工作，没有错误）
2. 分离旧数据库
3. 删除空间的数据文件
4. 重命名日志文件（仍然保留它）
5. 从步骤 1 的新备份中恢复数据库的新副本。

我对此的担忧/焦虑是：

• 这应该工作吗？或者是更安全/更可靠的方法？
• 我只有 2 小时，那么有没有更省时的方法？

欢迎任何其他建议。

Answer 1

如果您的日志文件已损坏，我担心备份/恢复会保留损坏。我的方法（可能会更快完成）是：

1. 运行完整备份。
2. 分离数据库。
3. 删除/重命名日志文件。
4. 附加数据库并重建日志文件。
5. 进行第二次完整备份。

要附加数据库并重建日志文件，它只是CREATE DATABASE语句中的附加语法：

CREATE DATABASE [foo]
ON (FILENAME=<<Path to data file>>)
FOR ATTACH_REBUILD_LOG;

这将强制 SQL Server 在附加数据库时重建日志文件。

这样做的风险是丢失在完成完整备份和分离数据库之间发生的任何事务，但听起来这将是最小的风险。如果您可以在停机时间窗口开始时“冻结”Sharepoint，这将有助于降低该风险。