在一个始终在线的群集设置中，您能将恢复模式从完全模式切换到简

解答动态

• 

  DBA是正确的-如果数据库是可用性组（AG）的一部分，它必须处于完全恢复模式。这是因为AGs的工作方式—它们将事务日志块从主服务器传送到辅助服务器。因此，需要完整恢复模型提供的所有详细日志记录。
  您可以在初始数据加载期间从AG中删除数据库。
  ALTER AILABILITY GROUP[YourAG]remove database[YourDatabaseName]； 但是，这样做的（潜在的主要）缺点是，次要数据库需要重新初始化一次数据加载完成。这意味着要么使用“自动种子设定”将整个主数据库复制到辅助服务器（在现有可用性组上启用自动种子设定），要么对主数据库进行备份，在每个辅助服务器上还原它，然后将数据库重新添加到AG（准备一个辅助数据库以备随时可用）
  根据数据加载后数据库的大小，这可能是“没什么大不了的”，也可能是一个真正的麻烦。但是，这是DBA基本上可以使用的另一个选项这：我们是在活动中看到一堆处于等待状态的查询
  您没有提到实际的等待，但是除非是HADR\u SYNC\u COMMIT或WRIOG，否则从AG/切换到简单恢复可能没有帮助。
  即使这些如果你在等待，请注意你正在治疗一种症状。如果应用程序在上线后需要像这样转储数据，你可能无法使用AG或恢复模型。
  也许你的应用程序可以通过将一些事务分组到更大的批处理中来减少生成的日志数据量。
  也许你需要调查主服务器和辅助服务器之间的网络速度（记住如何正确测量AG）不过，这些只是一些可能的补救措施。所有这些只是说，从长远来看，您最好现在就找出导致应用程序错误的“等待状态”的根本原因，而不是以后。
  您显示的等待是锁等待，表示经典的阻塞链。
  请注意，对于截图。这是“会话ID”（活动的第一列）。继续该链，直到找到lead blocker（quot；将为空），然后查看quot；列以查看它在等待什么。这就是你应该集中精力解决问题的根本原因。
  
• End