重建事務日誌

我們有一個非常大的數據庫（約 6TB），其事務日誌文件已被刪除（在 SQL Server 關閉時。我們嘗試過：

1. 分離和重新附加數據庫；和
2. 取消刪除事務日誌文件

…但到目前為止沒有任何效果。

我們目前正在執行：

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

…但是考慮到數據庫的大小，這可能需要幾天時間才能完成。

問題

• 上面的命令和下面的命令有區別嗎？

 DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• 我們應該執行REPAIR_ALLOW_DATA_LOSS嗎？

值得注意的是，數據來自其他來源，因此可以重建數據庫，但是我們懷疑修復數據庫比重新插入所有數據要快得多。

---

更新

對於那些記分的人：ALTER DATABASE/REBUILD LOG命令在大約 36 小時後完成並報告：

警告：數據庫“dbname”的日誌已重建。事務一致性已失去。RESTORE 鏈已損壞，伺服器不再具有先前日誌文件的上下文，因此您需要知道它們是什麼。

您應該執行 DBCC CHECKDB 來驗證物理一致性。數據庫已置於 dbo-only 模式。當您準備好使數據庫可供使用時，您將需要重置數據庫選項並刪除任何額外的日誌文件。

然後我們執行了一個DBCC CHECKDB（大約需要 13 小時），它是成功的。假設我們都了解了數據庫備份的重要性（以及授予項目經理訪問伺服器的權限……）。

永遠不要分離可疑數據庫。無論如何，分離後如何附加數據庫？你用過選項嗎CREATE DATABASE？FOR ATTACH_REBUILD_LOG

這些命令應該可以解決問題：

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

我針對這種情況寫了一篇文章：

SQL 2005/2008 數據庫恢復過程 – 日誌文件已刪除（第 3 部分）

您詢問了以下之間的區別：

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)和
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

問題是您可以執行兩者來重建日誌文件，但同時CHECKDB重建日誌並檢查數據庫是否存在完整性錯誤。

如果日誌文件失去時存在活動事務（未寫入磁碟），第二個（更改數據庫）也將不起作用。在啟動或附加時，SQL Server 將希望從不存在的日誌文件中執行恢復（回滾和前滾）。當磁碟崩潰或伺服器意外關閉並且數據庫未完全關閉時，就會發生這種情況。我想這不是你的情況，一切都對你有好處。

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)在緊急狀態下在數據庫上執行檢查數據庫是否存在不一致錯誤，首先嘗試使用日誌文件從任何不一致中恢復。如果缺少，則重新建構事務日誌。
2. ALTER DATABASE REBUILD LOG ON...是一個未記錄的過程，需要後續DBCC CHECKDB才能修復任何錯誤。

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