在一個始終在線的群集設(shè)置中，您能將恢復(fù)模式從完全模式切換到簡

解答動態(tài)

• 

  DBA是正確的-如果數(shù)據(jù)庫是可用性組（AG）的一部分，它必須處于完全恢復(fù)模式。這是因為AGs的工作方式—它們將事務(wù)日志塊從主服務(wù)器傳送到輔助服務(wù)器。因此，需要完整恢復(fù)模型提供的所有詳細日志記錄。
  您可以在初始數(shù)據(jù)加載期間從AG中刪除數(shù)據(jù)庫。
  ALTER AILABILITY GROUP[YourAG]remove database[YourDatabaseName]； 但是，這樣做的（潛在的主要）缺點是，次要數(shù)據(jù)庫需要重新初始化一次數(shù)據(jù)加載完成。這意味著要么使用“自動種子設(shè)定”將整個主數(shù)據(jù)庫復(fù)制到輔助服務(wù)器（在現(xiàn)有可用性組上啟用自動種子設(shè)定），要么對主數(shù)據(jù)庫進行備份，在每個輔助服務(wù)器上還原它，然后將數(shù)據(jù)庫重新添加到AG（準備一個輔助數(shù)據(jù)庫以備隨時可用）
  根據(jù)數(shù)據(jù)加載后數(shù)據(jù)庫的大小，這可能是“沒什么大不了的”，也可能是一個真正的麻煩。但是，這是DBA基本上可以使用的另一個選項這：我們是在活動中看到一堆處于等待狀態(tài)的查詢
  您沒有提到實際的等待，但是除非是HADR\u SYNC\u COMMIT或WRIOG，否則從AG/切換到簡單恢復(fù)可能沒有幫助。
  即使這些如果你在等待，請注意你正在治療一種癥狀。如果應(yīng)用程序在上線后需要像這樣轉(zhuǎn)儲數(shù)據(jù)，你可能無法使用AG或恢復(fù)模型。
  也許你的應(yīng)用程序可以通過將一些事務(wù)分組到更大的批處理中來減少生成的日志數(shù)據(jù)量。
  也許你需要調(diào)查主服務(wù)器和輔助服務(wù)器之間的網(wǎng)絡(luò)速度（記住如何正確測量AG）不過，這些只是一些可能的補救措施。所有這些只是說，從長遠來看，您最好現(xiàn)在就找出導(dǎo)致應(yīng)用程序錯誤的“等待狀態(tài)”的根本原因，而不是以后。
  您顯示的等待是鎖等待，表示經(jīng)典的阻塞鏈。
  請注意，對于截圖。這是“會話ID”（活動的第一列）。繼續(xù)該鏈，直到找到lead blocker（quot；將為空），然后查看quot；列以查看它在等待什么。這就是你應(yīng)該集中精力解決問題的根本原因。
  
• End