如果鏡像失敗，事務日誌填充驅動器
我有兩台設置了鏡像的 SQL Server 2016 機器。這應該是熱備方案。
HDD 大小為 1TB，數據庫大小約為 600GB（僅 1 個 DB）。這是 90 天的存檔數據，每晚都會刪除超過 90 天的所有數據（通過首先使用/填充數據庫的外部應用程序自動刪除）。所以 600GB 是峰值數據庫大小，它不會超過，因為它會定期清理。
如果一台伺服器出現故障，或者鏡像由於任何其他原因而暫停，則問題出在事務日誌上。如果我正確理解了原理，健康的伺服器將保留事務日誌，只要它沒有從合作夥伴那裡獲得一切正常的資訊。因此，如果鏡像失敗，硬碟將在幾個小時內被填滿。
有沒有合適的技術來防止這種情況？我每 15 分鐘備份一次日誌，一切正常，但如果鏡像被暫停，備份就沒有多大價值，因為儘管有備份，日誌仍會繼續增長。而且現場的情況有點具體，沒有工程師，只有每天訪問一兩次數據的操作員，所以不可能馬上做出反應。有人處理問題可能需要超過 24 小時。
我唯一能想到的是某種觸發器，一旦鏡像暫停一段時間（或者如果它被暫停並且硬碟空間太低），它就會完全刪除鏡像。這將防止健康的伺服器完全崩潰，但必須有人再次來到現場並從頭開始設置鏡像。而且由於從一開始就設計不好，DB大小大於HDD大小的一半，所以我什至無法創建本地備份/恢復，我必須通過屬於客戶端的100Mbps NAS來做所有事情。這將比事務日誌再次填充驅動器所花費的時間更多。
現在我正在考慮設置一個腳本，例如每半小時執行一次，如果日誌大小高於 200GB，則刪除鏡像。有什麼更漂亮的方法來做到這一點？另外，如果日誌達到最大大小，鏡像會發生什麼？所有事務都很小並且可以快速回滾，因此我還考慮將最大日誌大小設置為略高於之前的門檻值（可能為 250GB）作為額外的預防措施。這有什麼缺點嗎？
編輯1：我也想把這個放在最初的問題中，也許我的問題不夠清楚，但我沒有鏡像被暫停的問題，它執行良好（目前），我只是在為最壞的情況做準備。主要目標是完全冗餘，如果沒有任何預防措施，如果只有一台電腦出現故障，應用程序將因為硬碟驅動器而無法使用，它會在幾個小時內發生。
我從您的問題中看到的是，您沒有解決根本原因，而是圍繞核心問題建構解決方案，這些解決方案將重新出現，直到您解決根本原因 -**為什麼鏡像會暫停？**您是否在錯誤日誌（Windows 或 sql server）中看到任何錯誤？它是否經常發生，導致這種情況的模式是什麼？
先解決以上問題。一旦解決了根本原因，您就不必為 600GB 數據庫重新設置鏡像。
這是我在目前環境中所做的-
有一個過程來檢查鏡像執行狀況，例如使用 powershell 或 sql 代理作業：
select db_name(database_id) as MirrorSuspendedDBs from sys.database_mirroring where mirroring_state_desc = 'SUSPENDED' and mirroring_role = 1如果發現任何掛起的 db/s，請嘗試使用以下命令恢復鏡像
ALTER DATABASE dbname SET PARTNER RESUME;如果上述失敗（使用錯誤程式碼來擷取錯誤，可能會通過在重試之間休眠來重試 2-3 次），為 DBA 團隊生成票證或電子郵件。
這樣，您就知道出了問題並解決了該問題以進行永久修復。
看到這個：為什麼事務日誌不斷增長或空間不足？
編輯：
如果一台伺服器出現故障，或者鏡像由於任何其他原因而暫停，則問題出在事務日誌上。如果我正確理解了原理，健康的伺服器將保留事務日誌，只要它沒有從合作夥伴那裡獲得一切正常的資訊。因此，如果鏡像失敗，硬碟將在幾個小時內被填滿。
對於鏡像或 AlwaysON，輔助節點必須啟動，以便 tlog 被 sql server 截斷和重用。
如果您擔心由於 Tlog 沒有被截斷而導致二級伺服器出現故障並且您的驅動器被填滿，那麼請考慮切換到日誌傳送**，前提是它不會破壞您的 RTO（您可以多快啟動系統）和 RPO（多少數據失去是您的企業可以接受的）**。
鏡像的故障轉移幾乎是即時的，而日誌傳送（如果您沒有配置見證）是手動的。
您甚至可以使用集群 - DR-1（每側集群 2 個節點）和 2 個站點之間的鏡像。
再說一遍 - 為失敗做準備是一件好事，但在選擇 HA/DR 技術時，一定要測試所有場景。
數據庫大小約為 600GB（只有一個 DB）。這是 90 天的存檔數據，
您可以通過引入Columnstore 表來解決這裡的難題，並將數據庫大小減小到您不必立即做出反應以防止驅動器填滿的程度。