在小的停機時間視窗中修復損壞的日誌文件

我正在與一位客戶合作，該客戶從其 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 子系統存在問題，我們一直在與 Hosting Provider 一起努力。具體來說，這似乎是 /a 磁碟上的一個“壞點”，因為該 DB 的日誌文件一直報告它，但過去幾周其他 6 個 DB 日誌備份沒有報告其他錯誤，也不用於任何 20 多個其他數據庫的完整數據備份。

我的直接問題是客戶已經以這種方式執行了幾個星期，因為這是一項強制性的 24x7 服務，直到今晚（突然）2 小時，他們才能給我一個停機服務視窗來解決這個問題. 不幸的是，數據庫損壞和這種管理工作不是我在 SQL Server 中的專長，我不確定最好/最安全/最可靠的方法是什麼。

我現在的初步計劃是：

1. 停機時間視窗開始後立即對數據庫進行完整備份（在此期間完整備份一直在正常工作）
2. 分離舊數據庫
3. 刪除空間的數據文件
4. 重命名日誌文件（仍然保留它）
5. 從步驟 1 中的新備份還原數據庫的新副本。

我對此的擔憂/焦慮是：

• 這應該工作嗎？還是更安全/更可靠的方法？
• 我只有 2 小時，有沒有更省時的方法？

歡迎任何其他建議。

如果您的日誌文件損壞，我擔心備份/恢復會保留損壞。我的方法（可能會更快完成）是：

1. 執行完整備份。
2. 分離數據庫。
3. 刪除/重命名日誌文件。
4. 附加數據庫並重建日誌文件。
5. 進行第二次完整備份。

要附加數據庫並重建日誌文件，它只是CREATE DATABASE語句中的附加語法：

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

這將強制 SQL Server 在附加數據庫時重建日誌文件。

這樣做的風險是失去完成完整備份和分離數據庫之間發生的任何事務，但聽起來這將是一個最小的風險。如果您可以在停機時間視窗開始時“凍結”Sharepoint，這將有助於降低該風險。

引用自：https://dba.stackexchange.com/questions/63653