日誌文件收縮後，具有複製和鏡像的數據庫卡在 LOG_BACKUP 中

需要 SQL Server 專家的建議。我只是一個開發人員，而不是 DBA，所以請原諒我的無知。

我的環境由 SQL Server 2008 R2 x64 (10.50.4339.0) 的 2 個相等實例（Node1 和 Node2）組成。我有 2 個數據庫：具有Full恢復模型的 DB1 和 DB2。兩個數據庫在單個 SQL 實例中參與彼此之間的複制，並且它們都從 Node1 鏡像到 Node2。這些不是生產數據庫，我在進行任何更改之前確實進行了完整的數據庫備份。

但是，我最終遇到了麻煩：主體的 DB1 和 DB2 的日誌文件都沒有增長，並且執行：

select log_reuse_wait_desc, name, * from sys.databases where name='DB1' or name='DB2'

顯示 DB1 和 DB2 都有 `log_reuse_wait_desc=‘LOG_BACKUP’ 即使我確實手動執行了日誌備份。

以下是導致目前狀態的事件序列：

1. 我需要用涉及執行許多結構和數據更改腳本的年度更改集來更新 DB1 和 DB2。一些數據腳本非常繁重，會截斷表並包含 70K+ INSERT 呼叫。所以，我開始一點一點地在 Principal (Node1) 上應用更改。
2. 節點 1 在帶有 DB1 和 DB2 數據和日誌文件的分區上的可用磁碟空間有限。
3. 多次應用更改時，我收到了log file full...消息。所以我已經停止並將 DB1 和 DB2 的日誌文件縮小到 0Mb 以釋放一些磁碟空間來完成數據/結構更新任務。
4. 兩個數據庫的日誌文件確實縮小到允許的最小值，但是在我繼續進行數據更改後，我收到以下消息：

消息 9002，級別 17，狀態 2，第 1 行 數據庫“DB2”的事務日誌已滿。要找出日誌中的空間不能被重用的原因，請參閱 sys.databases 中的 log_reuse_wait_desc 列

有時在執行數據/結構更改腳本期間，相關分區的可用磁碟空間下降到幾 KB，並且 SQL Server 發送了警告電子郵件。

我確實嘗試研究如何讓log_reuse_wait_desc列顯示NOTHING。但是，建議的解決方案提示將 DB1 和 DB2 置於簡單恢復模式或分離/重新連接它們，由於複製和鏡像，我無法做到這一點。

我還遵循了Paul S. Randal的建議，並手動執行了日誌備份：

BACKUP LOG DB2 TO DISK = 'z:\DB2.TRN'

成功完成，但是log_reuse_wait_desc仍然顯示LOG_BACKUP並且日誌文件沒有增長。

DBCC LOGINFO 輸出：

DB1：421 條記錄，例如：

DB2：381 條記錄，例如：

DB2 的初始 loginfo 記錄：https ://i.stack.imgur.com/TTsVu.png

注意，FieldDB1 的列包含值 2 和 4，而 DB2 的Field列只包含值 2。文件大小和偏移量欄位看起來很嚇人：54GB+？我可能沒有那麼多空閒空間。目前驅動器上有 26GB 的可用空間，並且沒有減少。所以似乎 SQL Server 已經掛起。

有什麼方法可以修復目前的 DB1 和 DB2，而不禁用複制/鏡像，然後從備份中恢復？

任何幫助是極大的讚賞。

我想知道您的操作是否在事務日誌中產生了一些間隙，這可能會阻止虛擬日誌文件循環回到物理日誌文件的前面。從概念上講，這是到達物理文件末尾時數據庫中應該發生的事情：

如果DBCC LOGINFO返回的記錄表明物理日誌文件開頭的 VLF 的狀態為 2，則需要清除這些 VLF，在 Full Recovery 模式下，意味著必須進行 TLog 備份。我相信這種情況也會導致log_reuse_wait_desc列顯示LOG BACKUP。要解決此問題，您必須強制邏輯標題回到物理文件的開頭以清除這些狀態 2 VLF（並希望讓您的log_reuse_wait_desc列恢復顯示NOTHING）。為此，請執行以下步驟（可能需要在 DB1 和 DB2 數據庫上執行）：

1. 對數據庫執行日誌備份（例如）BACKUP LOG [DBNAME]...
2. 對事務日誌文件執行DBCC SHRINKFILE操作，指定 1 MB 作為目標大小
3. 對數據庫執行另一個日誌備份
4. 對事務日誌文件執行另一個DBCC SHRINKFILE操作，指定 1 MB 作為目標大小
5. 根據 Kimberly Tripp 的文章，手動增加日誌文件的大小，以將 TLog 恢復到適當的大小。

那麼這裡發生了什麼？

1. 第一個日誌備份僅生成已刷新到磁碟的已完成事務的備份，並從邏輯事務日誌中刪除不活動的虛擬日誌文件，從而釋放空間以供邏輯日誌頭重用。
2. 第一個 DBCC Shrinkfile 操作將物理 TLOG 縮小到目前邏輯日誌頭所在的位置，從而釋放盡可能多的空間。
3. 第二個日誌備份操作現在能夠在邏輯日誌內循環並備份/清除位於邏輯日誌標頭之前的任何剩餘非活動 VLF。無論出於何種原因，這些過去可能從未刷新過，但此時應該清除它們。此步驟對於解決您的問題至關重要，有時此備份可能需要一些時間，具體取決於需要將多少數據寫入磁碟。
4. 第二個 DBCC SHRINKFILE 操作將邏輯日誌頭移動到物理日誌文件的前面，消除了現在可能存在的過多 VLF，並將 TLOG 文件減小到非常小的大小，在本例中為 1MB。必須在第 5 步中手動增加文件，這樣您就不會再遇到 VLF 問題
5. 手動增加 tlog 的大小將允許您控制物理日誌文件中 VLF 的大小和數量。這是正確配置它的好時機，因此請充分利用。

關於該過程的最後一點說明。如果您的 tlog 非常活躍，您可能需要執行幾次或在活動減少的視窗期間執行此操作。高活動可能會導致在您執行第二次日誌備份之前發生另一個錯誤的自動增長事件。這基本上將您認為的第 3 步變成了第 1 步。通常第 1 步和第 2 步過得很快，而第 3 步需要最長的時間才能完成。確保執行第 4 步和第 5 步。

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