我需要帮助理解我的选择。鉴于：
- 由 DBA 维护的 SQL 服务器集群设置。
- 系统尚未投入生产（未移交给客户）。
- 最初的大量数据推送，连续几天没有中断
- 我可以随时停止和启动数据推送并更改数据库。基本上我可以停止所有输入。
我建议我们的 DBA 切换到简单模式，因为我们在活动监视器中看到一堆处于等待状态的查询，最终导致应用程序服务器出错。
我以前从未遇到过这个问题，在消除过程中我看到我们处于完全恢复模式而不是简单模式。
我要求我们从 FULL 切换到 SIMPLE，这就是我得到的答复。是否有其他选择可能是 DBA 不知道的？
我能提供什么帮助？
“我们无法在 SQL 中使用 AlwaysOn 切换到简单模式。”
我可以在初始加载阶段关闭 AlwaysOn 还是我不走运？
- - 添加 - -
DBA 是正确的 - 如果数据库是可用性组 (AG) 的一部分，则它必须处于完整恢复模式。这是因为 AG 的工作方式——它们将事务日志块从主服务器传送到辅助服务器。所以需要FULL恢复模型提供的所有详细日志记录。
您可以在初始数据加载期间从 AG 中删除数据库。
但是，这样做的（可能主要的）缺点是，一旦数据加载完成，辅助节点将需要“重新初始化”。这意味着要么使用“自动播种”将整个主数据库复制到辅助服务器（在现有可用性组上启用自动播种），或者对主数据库进行备份，在每个辅助服务器上还原它，然后将数据库重新添加到 AG（为 Always On 可用性组准备辅助数据库）。
根据数据加载后数据库的大小，这可能“没什么大不了的”，也可能是一个真正的麻烦。但是，是的，这基本上是 DBA 可用的另一种选择。
顺便说一句，关于这个：
您没有提到实际的等待，但除非它是
HADR_SYNC_COMMITorWRITELOG，否则从 AG 中删除/切换到 SIMPLE 恢复可能无济于事。即使这些是您的等待，请注意您正在治疗症状。如果应用程序一旦上线就需要转储这样的数据，您可能无法使用 AG 或恢复模型。
也许您的应用程序可以通过将其一些事务分组为更大的批次来减少生成的日志数据量。
或者您可能需要调查主服务器和辅助服务器之间的网络速度（记住如何正确测量 AG 吞吐量）。
这些只是一些可能的补救措施。所有这一切都只是说，从长远来看，现在而不是以后找出这种“等待状态导致应用程序错误”业务的根本原因会更好。
您显示的等待是锁定等待，表示典型的阻塞链。
请注意，屏幕截图中所有行的“阻止者”列都是 131。那是一个“会话 ID”（活动监视器的第一列）。继续跟踪该链，直到找到领先的阻止者（“阻止者”将为空白），并查看“等待类型”列以查看它在等待什么。这就是你应该集中精力找出根本原因的地方。
关于本次更新：
听起来事务日志备份发生时增加的资源使用量会干扰您的工作负载。一种解决方案是像 DBA 那样更频繁地运行事务日志。如果备份完成得足够快，您甚至可以每分钟运行一次备份。
综上所述，如果在初始加载完成后重新初始化辅助节点是可行的，则切换到 SIMPLE 恢复的原始解决方案是一个可行的选择。