标签: availability-groups

我的环境有 2 台 Windows Server 2012 R2 服务器，均带有 SQL Server 2014 昂贵版本。

每当 AG 中发生更改（例如：在可用性副本“SecondaryReplicaThatIRestarted”上为主数据库“AGDatabase”建立与辅助数据库的 AlwaysOn 可用性组连接）时，我会在 SQL 错误日志中收到如下错误：

来源：SPID52s

消息
DbMgrPartnerCommitPolicy::SetSyncState:00000003BFC0B0E0:1

以这样的结果结束：

Imgur：错误日志的屏幕截图

编辑：

Windows 错误日志中没有任何内容，甚至没有提到的错误，这让我相信这是 SQL 内部的某些内容泄漏到错误日志中。

您知道这可能是由什么引起的吗？我已经设置了多个与此类似的设置，这是我第一次看到它。我计划本周将 SQL 修补到 SP1，但是我在发行说明中没有看到错误。

我用来sys.fn_hadr_backup_is_preferred_replica查询每个可用性组副本上的数据库，以确定是否应该在该副本上备份数据库 - 然后，如果该函数返回 true，则检查msdb.dbo.backupset数据库最近是否已备份。

我遇到的问题是该函数需要很长时间才能运行（每个数据库大约 3 秒） - 谁能推荐一个更快的替代方案？

为了回应下面的评论，我目前使用的是 SQL 2012 SP1 (11.0.3000.0) - 但是，我正在创建的查询需要针对多个客户站点上 SQL Server 2012 的多个不同安装，因此，即使这个系统功能在后续的更新中得到了改进，遗憾的是我可能无法强迫人们更新。

我已将一个数据库添加到已经拥有一些数据库的可用性组，所有这些数据库都已播种并同步到辅助数据库。

最后一个似乎被添加到可用性组中，但被标记为“不同步”并且不会返回任何错误。我已经尝试了多次，结果相同。

我查看了扩展事件、事件查看器......什么也没有。单击仪表板中的“警告”没有任何有用的信息。辅助数据库上根本不存在数据库文件。我怀疑它在播种过程开始时就被阻止了（但显然是在“添加到 AG”向导中的初始验证之后）。

我有一种明显的感觉，SQL Server 一定正在将相关的故障消息记录到一些我不知道的 DMV 中。

是否有一个规范的指南来指导人们应该在所有地方寻找与AlwaysOn相关的错误？

我的 SQL 服务器场因修补操作系统级别和 SQL 服务器级别而被忽略（因为它们是关键系统，很难发生中断）。

一种选择是在一个月内将我们的 AOAG 集群的辅助节点修补到最新的补丁，然后在下个月业务同意安排在几个小时内进行故障转移。然后我可以修补新的辅助节点（旧的主节点）。这意味着节点在一个月内不会处于相同的补丁级别......这是“不，不”吗？

使用 AlwaysOn，关键字有 3 个选项 MultiSubnetFailover

• 真（是）
• 错误（否）（示例）
• 未发送/使用

并非所有应用程序都支持在连接字符串中使用它。并非所有供应商联系人都了解故障转移对性能的重要性。

作为一名 DBA，我希望能够验证应用程序连接正在使用什么属性。如果我没有对其进行适当的设置更改，RegisterAllProvidersIP可能会导致问题。请参阅：后续：创建可用性组侦听器之后

它并不显得捕获在任sys.dm_exec_sessions也不sys.dm_exec_connections

如何捕获用于创建与我的实例之一的连接的（如果有）关键字值？

我在 SQL Server 2019 中创建了一个 AlwaysOn 并选择了自动播种，但它不会在辅助节点中创建我的数据库，另一方面，如果我手动创建我的数据库，我会给出您的数据库已经存在的错误！解决办法是什么？

我一直在 Always On High Availability 组中研究数据库，由于我不明白的原因，该组在主节点和辅助节点上对应用程序登录使用不同的默认语言。

我目前的特殊情况是这样的：

• 应用程序期望的语言是英式英语。它没有指定连接时使用的语言；它使用登录的任何默认语言。该应用程序的文档说默认语言应该是英式英语，大概是因为它没有指定连接语言。
• 应用程序连接到侦听器，而不是直接连接到任一节点。
• 应用程序通常将日期保存为字符串（例如UPDATE FooTable SET BarColumn = '01\02\2020' WHERE IdColumn = 42）。数据将保存在日期或日期时间列中。
• 数据库侦听器上登录的默认语言是英式英语。
• 主节点登录的默认语言为英式英语。
• 辅助节点登录默认语言为美式英语

我不是 DBA，当然也不是 Always On High Availability 方面的专家。使用此配置可​​能存在/已经存在哪些危险？如果交换主节点和辅助节点上的语言是否重要？

我们最近从 LogShippingstandby/read-only设置迁移到具有可读辅助设备的多子网 AG 设置。

通常，在旧设置中，我们会选择运行较长时间的查询，因为相关数据库超过 20 TB，并且主数据库上有混合读写工作负载。

在转移到 AG 的新设置后，我们开始看到我无法理解的阻塞。为什么辅助选择查询会阻止我的可读辅助副本实例中的其他选择查询，即使正在查询的数据库有RCSI enabled？

以下是我捕获的内容

• 主要阻止程序是一些长时间运行的SELECT查询，不会显示任何特定的等待类型，例如 SPID129

• SPID 129阻止会话 ID 45（我确信这不是用户 ID）近 6 小时，这取决于 spid129 并且等待类型是 LCK_M_SCH_M

• SPID 45当这在 6 小时的持续时间内阻止所有其他选择查询时，问题就来了。

我无法理解发生了什么。有人可以帮助我排除故障或寻找正确的方向吗？

属于 SQL Server Always Availability Group 的一部分的数据库（具有用于横向扩展只读工作负载的同步和异步LOB_DATA可读辅助数据库）正在经历分配类型的版本幽灵记录的累积。

这种情况发生在应用了高级别的INSERT操作的表上。

REBUILD对该表的聚集索引的删除将删除分配类型的任何版本幻影记录IN_ROW_DATA，但不会删除分配类型的版本幻影记录LOB_DATA。

执行手动故障转移会删除版本幻影行，但这是不可取的。

当我调查版本幽灵行累积的根本原因时，是否有其他方法可以删除分配类型的版本幽灵记录LOB_DATA？

我们最近将 AOAG 集群故障转移到了次要区域。在第一个区域，我们的盒子有 32 个核心，而在第二个区域，我们有 64 个核心。流量相似，但是在较大的机器上，我们在 sys.dm_os_workers 中运行更多数量的工作线程（以及 sys.dm_os_threads 中的线程）。这是提高 CPU 核心时的预期行为吗？还是我们应该担心所有这些闲置的工作人员？

我们正在运行 SQL Server 2017 CU 24。

max worker threads配置为0（默认值）。

max degree of parallelism在两个区域都配置为2。

在当前服务器中，我们看到以下计数：