JasonBluefire's questions

我们有一个四节点可用性组，一个站点中有两个节点，另一个数据中心中有两个节点。我注意到在 WAN 连接不稳定的每个 WAN 问题之后，异地节点不断断开连接并重新连接（使用 AOAG 仪表板中的 AOAG 运行状况），主服务器的内存被“HADR 日志块消息池”消耗

SELECT  *
FROM    sys.dm_os_memory_clerks
ORDER   BY pages_kb DESC

类型：OBJECTSTORE_SERVICE_BROKER
名称：HADR 日志块消息池

在最坏的情况下，当网络震荡数小时时，这个内存管理员将最终消耗掉 SQL Server 超过 90% 的内存，导致 SQL Server 停止运行（SQL 有 10GB 的内存“HADR Log Block Msg Pool”正在使用 9.8GB）。

有什么办法可以转储这个 HADR 日志块消息池吗？或者从一开始就阻止它变得如此之大？到目前为止，我们唯一的解决方案是故障转移并重新启动盒子。

没有错误，只有节点断开连接和重新连接的日志以及重新连接后重新加固的数据库的日志。

随着越来越多的内存被“HADR 日志块消息池”占用，可用于其他所有内容的内存下降，从而影响性能。通常这 10GB 的 RAM 适合这个 AOAG 组和用途。只有当 WAN 抖动一段时间后，我们才会遇到这个问题。

我们可以在服务器上投入更多内存，但我认为这不会解决根本问题，它只会在严重损害性能之前为我们争取更多时间。

我同意网络是根本原因，但在问题解决并且 AOAG 恢复同步后，SQL 不会像大多数 SQL 内存管理员那样将 RAM 恢复/重新分配给其他 SQL 内存管理员，这似乎很奇怪。

日志传送将不起作用；这是一个交易环境，我们需要近乎实时的，最好是实时的异地灾难恢复。AOAG 小组 99% 的时间都在工作，而且几乎总是实时同步。我们正在尝试与网络团队合作以改善连接性，和/或可能会使其断开连接而不是抖动。

系统信息
SQL 版本：SQL 2016 SP1 CU6 13.0.4457.0
操作系统版本：Windows 2012 R2 6.3.9600
服务器内存：12GB
SQL 最大内存：10GB

Availability Group config info
AOAG 中有四个数据库
AOAG 数据库加起来是 364GB
两个本地节点处于同步模式，每人一票
两个远程节点处于异步模式，零票
还有一个本地文件见证，一票.

SQL Server 2014 SP2 CU10 补丁卸载卡在 DowntimeTimingConfigAction。

它已经在“更新‘[Instance Name]’：DowntimeTimingConfigAction”这一步将近 2 个小时了。

什么是 DowntimeTimingConfigAction？在什么时候我应该称之为失败的原因？

我在任何地方都找不到太多关于它的信息。

我有很多工作需要运行，但它们不能同时运行。每个检查的第一步都是检查是否有其他人正在运行，如果是，它会稍等片刻并再次检查。这可能导致两个作业相互等待完成的锁定情况。

内置重试不起作用，因为它们在等待重试时被认为正在运行。我可以出错并让作业每 10 分钟运行一次，检查它上次成功运行的时间以及是否有其他人正在运行。然后再次运行或出错，但这可能会导致作业发生偏离计划。

我环顾四周，但找不到任何东西，所以我不知道这是否可能，但你能设置一个时间表，比如此时从另一个工作中运行这个工作吗？

或者有没有我忽略的更好的方法？