问题标签 [alwayson]

我在alwayson 中的一个复制品停机了几分钟。我的问题是，辅助副本可以关闭多长时间？我可以从 dmv 表或其他地方得到它吗？10X

我当前的环境在一个虚拟机上：

• TFS2013
• SQL Server 2012（专用实例，安装在同一个虚拟机上）
• 1个项目集合
• 已配置报告

我的迁移目标环境是：

• 包含 TFS 2017 更新 1 的新 VM
• 现有 SQL Server 2014 AAG，无 SSAS
• 未配置报告（因为未安装 SSAS），我实际上不需要报告

我尝试了多种方法来进行此安装，但遇到了很多关于 Always-On 的问题：

1. 直接在 AAG 中使用数据库还原（通过 SQL Management Studio）直接升级/配置，遇到 TF400711 错误

2. 在没有 Always-On 的情况下升级/配置，效果很好，但现在我的问题是将我的数据库移动到 AAG。Tfs_Configuration 是可以的，但是当我附加我的集合时，遇到 TF246017 错误。我不理解这个错误，因为我使用与 Tfs_Configuration 数据库相同的连接字符串......

就我而言，最好的程序是什么？

我阅读了这篇文章和这篇文章，但它们与我的情况不符。

每当我在 SQL Server Always On Cluster 上终止一个 Select 查询时，它都会转到 ROLLBACK 并挂起。

我是否需要停止与辅助节点的同步提交模式，然后终止会话，然后启动同步？

我有 3 台服务器。

服务器 A，带有发布数据库，此服务器不属于 alwayon 组，此服务器是分发服务器

服务器 RT1 和 RT2，这些服务器作为 alwayson 组的一部分

监听器 RT，监听器订阅了服务器 A，里面有 RT1 和 RT2

问题是：RT2 是只读的，因为它是次要副本，所以到此订阅的所有复制都将在队列中，直到服务器成为主服务器（在故障转移时），这意味着当 RT2 成为主服务器时，将在队列中进行所有复制并开始复制一个接一个，然后 RT1 将是次要的，只读和队列中的复制问题

如果有另一种方法来配置复制到始终复制到主服务器的 Alwayson 组，并且在故障转移的情况下切换连接，而只读服务器的队列中没有复制？

注意：服务器A不是alwayson组的一部分，服务器A也是发布者，RT1或RT2不能是发布者

提前致谢

我的项目数据库很大，并且有多个存储过程作业按计划运行。基本上它是数据库性能的瓶颈。我想将负载分配到不同的数据库服务器并将数据合并回主数据库。

我的问题是：我该如何管理？哪种方法最有效？

我的计划：主数据库将数据复制到多个数据库特定的作业/SP 将在副本数据库上执行一旦作业完成，将数据（使用 ssis）合并到主数据库

关于如何解决它的任何想法或建议？

我的任务是监控 SQL AlwaysON 的性能。我编写了一个脚本，它将返回 AlwaysON 可用性组信息，如下所示：

如何将结果“旋转”到 1 行，如下所示：

我正在寻找一种类似于 Splunk 中的“图表”命令的方式，它通过 secondary_replica 跨越多个值的列

我写了一个查询来提取 SQL AlwaysON 健康信息。剩下要做的就是在最后添加一个 where 子句来过滤 AvailabilityGroupName 和 DatabaseName。当我输入查询时它起作用：'select * from results where AvailabilityGroupName ='LAB-VIP-USADB' AND DatabaseName ='CPS''。但是，当我在开始时将查询存储在 nvarchar 变量 @sql 中并稍后执行存储在变量中的查询时，我收到错误消息“关键字'EXEC'附近的语法不正确”。我想参数化查询的原因是一个可用性组可以包含多个数据库。参数化输入将来自 PRTG，以便查询该特定数据库的可用性组。

我尝试了很多东西并分析了很多文件，但我还没有找到解决方案。

我在 VmWare 中有三个虚拟机，称为 (DC,SQLServer01,SQLServer02)。所有 SQL Server 都是域的成员。（DC）我为 SQLServer01 和 SQLServer02 安装了故障转移集群。我在 SQLServer01 中做了必要的配置。然后我为两台服务器安装了 SQL Server 2014。现在，我创建了一个 alwaysOn 组。SQLServer01 是主要的，其他是次要的。当我切断 SQLServer01 的连接时，一切都很好（次要变为主要）。其他情况可以接受。

但是，当所有服务器都在线时，除了在我的辅助副本中的读取操作之外，我无法执行任何操作（插入、更新、删除、更改等）。我总是看到“数据库是只读的”错误。在 Alwayson 组的属性中，主副本和辅助副本都具有所有连接，并且辅助可读为“YES”。

即使所有服务器都在线，我也想进行 CRUD 操作。（我的意思是，也为二级副本做所有事情。）

那么，您有什么建议或想法吗？

感谢您的时间和考虑。

有没有其他人遇到过这个？你的情况是如何解决的？它是由 SQL Server 之外的因素引起的吗？副本（主要到次要）或存储 IO 之间的网络传输？

我尝试询问基础架构团队是否可以在 VMWare vCenter 中检查某种类型的 QoS 或 DRS 策略，以防止对 VM 进行节流或洗牌。

此特定 VM 是 ASYNC 模式下的异地节点。该消息发生在一天中的不同时间并针对多个数据库。大多数情况下每天发生一次，但有时最多每天发生 4 次。间隔即。上午 3 点至 6 点，上午 10 点至下午 12 点。似乎取决于主节点上的活动工作负载。这只是一条信息性消息，之后同步确实进行得很好。

- - -原始信息 - - -

来自：不回复

发送：2017 年 8 月 11 日星期五凌晨 3:37

至：海勒姆

主题：SQL Server 警报系统：\SVRSQL02 上出现“其他用户错误”

日期/时间：2017 年 8 月 11 日凌晨 3:36:43

描述： Always On 可用性组传输检测到可用性数据库“MyDB”缺少日志块。最后应用的日志块的 LSN 是 (69168:224114:0)。将重新启动日志扫描以解决此问题。这只是一条信息性消息。无需用户操作。

评论：（无）

作业运行：（无）

我考虑启用跟踪标志 9587 以将 AG 恢复为顺序处理，但这似乎会降低性能。

参考： https: //support.microsoft.com/en-us/help/3201336/low-transaction-throughput-on-always-on-availability-group-primary-rep

Always On 可用性组主副本上的事务吞吐量低

症状：当您在 SQL Server 2016 中配置 Always On 可用性组时，您可能会遇到间歇性的低吞吐量期。发生此问题时，您可能还会注意到 HADR_SYNC_COMMIT 进程的等待时间很长。

此外，辅助副本实例上的错误日志报告以下错误：

错误：19432，严重性：16，状态：0 Always On 可用性组传输检测到可用性数据库“”缺少日志块。最后应用的日志块的 LSN 是 (xxx:xxxxxxxx:x)。将重新启动日志扫描以解决此问题。这只是一条信息性消息。无需用户操作。

解决方法：要解决此问题，请将跟踪标志 9587 添加为参与 Always On 可用性组配置的副本实例的启动参数。

SQL Server 的未来更新将不再需要使用跟踪标志 9587。此标志会导致可用性组的传输层恢复为顺序处理，从而禁用 SQL Server 2016 中 Always On 可用性组的性能吞吐量改进。除非您是遇到“症状”部分中描述的问题，我们不建议您应用跟踪标志 9587。

属性：文章 ID：3201336 - 上次审核：2016 年 10 月 25 日 - 修订：1

适用于：Microsoft SQL Server 2016 Standard、Microsoft SQL Server 2016 Enterprise、Microsoft SQL Server 2016 Developer

我正在使用 SQL Server 2014 企业版。

我在命名实例上创建了一个 alwaysOn 可用性组并为其配置了一个侦听器。

当我尝试从 SQL Server Management Studio 访问侦听器时，它会记录到默认实例。我将端点 URL 配置为指向命名实例，并为实例提供了一个静态端口

另请注意，我已将端点配置为在两个实例中侦听相同的端口。

我不知道为什么会这样。