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