Always On 日誌文件大於數據庫文件
我們有 SQL RAP，我們收到警告說事務日誌文件大於數據庫文件。
他們建議我從 Always On 中刪除數據庫，將恢復模式更改為
SIMPLE然後縮小日誌文件並將其放回 Always On。並更改維護計劃。T-LOG 備份每小時執行一次。但是第二天事務日誌文件又比數據庫文件大。由於這是執行 SharePoint 2013 數據庫，他們說可以將 SharePoint 2010 數據庫遷移到 2013，但我在另一個 Always On 群集（不是 SharePoint）上具有相同的行為。我還嘗試以相同的結果實施 Ola Hallengren 的維護腳本。在沒有 AO 的其他機器上沒有這樣的問題。
所以我不確定為什麼會發生這種情況，它與 Always On 有關嗎？我知道 Always On AG 數據庫需要更大的日誌文件，那麼這是 AO 中的正常行為嗎？
我看過事務日誌增長非常快。我只有
log_reuse_wait=2在日誌備份之間，一切看起來都按預期工作，但事實並非如此。我檢查了日誌發送隊列和重做隊列大小，看起來不錯，因為它只有*“2 日誌備份您正在等待日誌備份發生”。*在等待下一次日誌備份時。AOAG 健康狀況良好，頻寬綽綽有餘。日誌備份是每 15 分鐘一次。
所以我不確定為什麼會發生這種情況，它與 Always On 有關嗎？
它與 Always On 相關，也與 Always On無關。Always On 可用性組要求數據庫處於完全恢復模式——這就是您首先需要日誌管理的原因。只要您的次要副本與主要副本保持非常接近（即在數小時或數天內沒有滯後的次要副本），日誌管理就不會因為 AG 而受到太大影響。
我知道 Always On AG 數據庫需要更大的日誌文件，那麼這是 AO 中的正常行為嗎？
Always On 可用性組本身並不需要更大的日誌文件。通常它最終成為原因，因為大多數數據庫在對可用性組進行更改之前處於簡單恢復模型中，因此日誌管理對該數據庫來說是一個新概念。
如果數據庫處於簡單恢復模式並且日誌增長到 X GB，則最小日誌大小將為 X GB，無論恢復模式、始終開啟等如何。但是，由於日誌管理不再是自動的隨機數 (通常是 30 分鐘或一個小時）是任意選擇的，並且日誌管理在這些時間間隔內進行。現在日誌需要增長以適應日誌管理自動化的變化。
正如@Shawn Melton和@RDFozz在評論中所說的那樣 - 如果您不希望日誌變得太大並且您的所有副本都正確同步，那麼讓您的日誌管理更頻繁地發生。
由於這是執行 SharePoint 2013 數據庫…
SharePoint 以擁有自己的計時器作業而聞名，這些作業執行內部維護項目並儲存 blob 數據。這本身會導致日誌管理不善，您對此無能為力。因此，這個數據庫的日誌大於數據文件並不讓我感到驚訝。
當數據文件小於日誌時，這絕不是一個好兆頭，但我確實相信這種情況 - 除非您將日誌管理自動化更改為更短的間隔
$$ And even then it depends on what SharePoint does to the DB $$它很可能最終會保持這種狀態——這可能是正常的。在這種情況下，我們可以將其標記為正常並開始我們的一天。
我們有 SQL RAP，我們收到警告說事務日誌文件大於數據庫文件。
這是朝著正確方向（我為 Microsoft 工作）邁出的一大步，即對您的實例進行風險和健康檢查。這個特定的檢查是我們用來尋找可能有不當或沒有日誌管理的數據庫的東西。在某些情況下（我親自處理過），DBA 說過，“糟糕，不應該批量記錄……”我們將其改回簡單，因為它不需要任何時間點或擴展恢復選項。沒關係！但是，檢查確實讓每個人都有機會查看有問題的數據庫並確保沒有問題這就是關鍵的區別。就像我上面所說的，這可能只是正常的，沒關係 - 但是，如果我們不理會它並且什麼都不說，我們就不會正確地完成我們的工作，這很重要。
有趣的是，當我是一家大型服裝公司的 DBA 時，我們有一個第 3 方應用程序，它使用游標每 15 分鐘循環一次所有員工，並執行一個儲存過程，刪除他們所有的歷史記錄，然後從頭開始重建……在單筆交易中。數據庫為 50 GB，其日誌文件為…. 280 GB。這就是應用程序的工作方式，我記錄了與第三方供應商的投訴和可能的程式碼更改，並被立即駁回。它發生了，一些應用程序就是這樣執行的。
我按照以下步驟對我有用：
- 確保您處於正確的恢復模式
- 如果您需要時間點恢復，請設置事務日誌備份
- 縮小你的事務日誌文件（也許）
連結文章中的更多詳細資訊。