标签: availability-groups

问题：如何在 AlwaysOn 可用性组 (AG) 中的所有服务器上运行分布式事务协调器 (DTC)？我不需要在故障转移/切换事件上维护事务。

设置：我有一个带有三台 Windows 2008 R2 服务器的 Windows 故障转移群集 (WSFC)，它们都运行 SQL 2012。两台服务器位于一个数据中心，是 AlwaysOn 故障转移群集 (FCI) 的一部分，而第三台服务器位于第二个数据中心。WSFC 是一个多子网集群。这是设置的草图：

我已经能够安装和配置 DTC 以在两个 FCI 节点之间工作，因为它们位于同一子网上并共享存储。我已经配置了几个 AG，它们运行良好。此屏幕截图显示安装在 FCI 上的 DTC：

此屏幕截图显示我可以在其中一个 FCI 节点（以处于活动状态的节点为准）上配置 DTC：

我想将使用 DTC 的应用程序迁移到此集群并使用 AG。我读过 AG（参考）不支持 DTC 。我一直找不到在第二个数据中心的第三个节点上配置 DTC 的方法。当我尝试在第三个节点上配置 DTC 时，它似乎不可用，如下图所示：

在 Brent Ozar 的Free Setup Checklist PDF for Availability Groups 中，他列出了：

集群安装...

29. 如果涉及 FCI，请根据您的计划部分的决定配置 DTC。

In the comments on SQL Server 2012 AlwaysOn Availability Groups Rock Brent says that …

我们在 AlwaysOn 组中有 2 台服务器。

虽然每个同步数据库中的用户帐户都存在于两台服务器上，但数据库实例级登录仅存在于其中一台服务器上。即 DBINSTANCE->Security->Logins 在一台服务器上丢失。

因此，当发生故障转移时，我会在第二台服务器（没有相应的实例级别登录）上登录失败。

我如何克服这个问题？我应该以特殊方式设置用户帐户吗？

我有一个始终处于高可用性模式的数据库与不同实例上的另一个数据库同步。如何.bak使用将文件从文件还原到主数据库T-SQL？

我是高可用性的新手，有人建议我需要先将数据库从高可用性中移除，然后才能进行还原，然后再次将其恢复为高可用性，但我不确定。

我希望我可以在AlwaysOn仍然启用的情况下直接恢复到主服务器，并且它会自动与辅助服务器同步。

我的组织正计划采用 SQL Server 2012 可用性组，我正在尝试了解它将对我们的应用程序升级过程产生什么影响（如果有）。

我们每 8 周发布一次应用程序更新，任何发布都可能包括架构更改和/或数据迁移。

我想了解的是 HA/DR 解决方案是否透明地处理架构更改（新列、索引被添加到辅助节点），或者是否需要手动干预在每个实例上创建架构然后重新打开 Always On。

我假设的数据迁移部分是透明处理的，但也想确认一下。

我想我也做了一个笼统的假设，即基于可用性组配置的这些行为没有区别，这也可能是错误的。请告诉我。

简而言之; 在我的应用程序的任何给定版本中，我可能会通过向其中添加列来更改非常大的表（数百万条记录的数十到数百条记录）。某些列可能是“全新的”，因此它们可以使用 Enterprise Online 架构更改功能。其他列可能是现有列的重构（全名被拆分为名字和姓氏），并且将为表中的每一行运行迁移以填充这些字段。这些行为中的任何一个是否需要 DBA 更改 AlwaysOn 配置，或者这是默认处理的，并且所有辅助节点都“免费”获得 DDL 和 DML 语句？

感谢您提供的任何清晰度。

为什么 HADR 池中可用性组的工作线程数会增加到远远超过“通常每个副本有 3-10 个共享线程”的最低使用量？

在一种情况下，我们观察到 300 多个线程的使用情况，总共有 3 个可用性组和 10 个数据库。SQL Server 2014 SP1。

我们的线索是二级副本的备份、主副本的高活动、二级副本的报告。

AG 位于 VMware 上的数据中心。总共 16 个调度程序，通常的工作线程在 200 范围内。服务器上的max_dop为 2。

• 3 个 AG，10 个 DB，每个副本 4 个 - 主副本，2 个只读，1 个不可读。
• 1 个次要同步，2 个异步
• 大型多主机集群上 32 个物理内核上的 16 个 vcores。
• 没有过度供应。
• 其他较小的 4-8 核 VM 位于同一位置，但不会占用 CPU

我们观察到导致拒绝服务的工作线程激增。将工作线程归因于 AG 是我们的假设，因为只有那些工作线程才能跨越限制。

在上下文中阅读的 SQL Server Premier 现场工程师博客中的以下链接并没有给我一个完整的答案：

• 监控 SQL Server 2012 AlwaysOn 可用性组工作线程消耗
• 我的实际工作线程是否超过了 sp_configure 的“最大工作线程”值？

我在 Always On 可用性组中有一对 Microsoft SQL Server 2016 节点。我正在尝试对BULK INSERT位于 Windows Server 2016 文件服务器故障转移群集上的文件执行（使用 SQL Server 2016 Management Studio 查询），但出现以下错误：

消息 4861，级别 16，状态 1
无法批量加载，因为无法打开文件“\nas2.my.domain\Microsoft SQL Server 2016 Enterprise\test.txt”。操作系统错误代码 5（访问被拒绝。）。

无论我使用活动节点名称 ( nas2.my.domain) 还是故障转移群集侦听器 ( nas.my.domain)，都会发生这种情况。

环顾四周后，我发现这是由于 SQL Server 由于与BULK INSERT.

如果您使用 Windows 身份验证连接到 SQL Server，则 SQL Server 服务帐户在连接到文件服务器时会尝试模拟您的用户帐户。如果您使用 SQL Server 身份验证进行连接，它将以 SQL Server 服务帐户的身份连接到文件服务器。

如果委派和模拟配置不正确（默认状态），SQL Server 服务将无法模拟您的用户帐户，并将退回尝试以匿名用户身份连接到文件服务器。

这可以通过查看文件服务器上的安全事件日志来确认。这些事实以及有关配置无约束和约束委派的指南记录在以下链接中：

• 如何：具有约束委派的 SQL Server 大容量插入（访问被拒绝）

• 批量插入和 Kerberos

我已经尝试按照thesqldude的指南中的说明进行操作，但它仍然无法正常工作。

我尝试使用的数据库BULK INSERT不是可用性组的一部分，因此只有 MSSQL1 节点应该相关。文件服务器在 …

在传统的 SQL Server 群集中，当发生故障转移时，所有连接到 SQL Server 失败实例的客户端都会失去连接，每个客户端都必须重新建立到故障转移群集实例的新连接。

AlwaysON 可用性组是否可以缓解此问题？SQL Server 2012 AlwaysON 可用性组的故障转移对于连接到 SQL Server 的客户端是否透明？

我们正在使用 AlwaysOn 进行 SQL Server 2014 POC 测试，其中一位用户询问是否使用本地服务器组中的注册服务器保存具有只读意图的 SSMS 配置。这样他们就不必在每次需要访问只读副本时都输入别名。

不幸的是，与常规对象浏览器不同，注册服务器中没有选项可以添加 ApplicationIntent 选项。

我从 Microsoft 看到了这篇关于更改 RegSrvr.xml 中的连接字符串的文章。

https://connect.microsoft.com/SQLServer/feedback/details/786323/ssms-sql-server-management-studio-2012-missing-connection-properties-for-availability-groups

我尝试了他们的建议，但在通过注册服务器中的本地服务器连接时，它没有连接到正确的副本节点。

使用连接窗口 > 附加连接参数中的选项时，对象资源管理器中的只读选项工作正常。但它不会保存对连接所做的更改。

有没有人知道使用 SSMS保存具有只读意图属性的配置的任何替代解决方案？在此先感谢您的帮助。

在测试从 SQL Server 2014 SP1 (12.0.4422.0) 到 SQL Server 2016 CTP 3.2 (13.0.900.73) 的升级时，我遵循推荐的更新过程并遇到了一个问题，即故障转移后数据库无法在旧的主数据库上启动到更新的辅助。我们的设置是一个主副本和一个辅助副本，我完成的步骤是：

1. 删除同步提交辅助副本上的自动故障转移
2. 将辅助服务器实例升级到新版本
3. 手动故障转移到辅助副本
4. 验证数据库在新的主副本上是否在线
5. 将以前的主副本升级到新版本

升级辅助节点和故障转移使其成为主节点完全按预期工作。但是在升级以前的主副本后，我注意到其上的数据库在 SSMS 中列为Not Synchronizing / In Recovery。尝试访问它们也会生成错误消息：

数据库...无法访问。（对象浏览器）

通过我看到的 SQL Server 日志检查

无法打开数据库 '...' 版本 782。将数据库升级到最新版本。

查询master..sysdatabases表，确实是旧版本，升级过程中没有更新：

不幸的是，日志没有指出它为什么没有更新，并且可用性组仪表板只给出了一个通用警告，表明某些可用性数据库的数据同步状态不健康，没有任何原因。

我尝试使用 TSQL 分离数据库或将它们设置为离线以“踢”它进行更新，但由于它们是 SQL AG 的一部分，因此这些命令不起作用。

当数据库是 SQL AG 的一部分时，如何将数据库升级到最新版本？

我们最近在 SQL Server 2014 HADR 环境中遇到了一个问题，其中一台服务器用完了工作线程。

我们收到消息：

AlwaysOn 可用性组的线程池无法启动新的工作线程，因为没有足够的可用工作线程。

我已经打开了另一个问题，以获得（我认为）应该帮助我分析问题的声明（是否可以查看哪个 SPID 使用哪个调度程序（工作线程）？）。虽然我现在有查询来查找正在使用系统的线程，但我不明白为什么该服务器用完了工作线程。

我们的环境如下：

• 4 Windows Server 2012 R2
• SQL Server 2014 企业版
• 24 个处理器 --> 832 个工作线程
• 256 GB 内存
• 12 个可用性组（总体）
• 642个数据库（总体）

因此，出现问题的服务器具有以下配置：

• 5 个可用性组（3 个主要 / 2 个辅助）
• 325 个数据库（127 个主要 / 198 个辅助）
• MAXDOP = 8
• Cost Threshold for Parallelism = 50
• 电源计划设置为“高性能”

为了“解决”该问题，我们手动将一个可用性组故障转移到辅助服务器。该服务器的配置现在是：

• 5 个可用性组（2 个主要 / 3 个辅助）
• 325 个数据库（77 个主要 / 248 个辅助）

我正在使用以下语句监视可用线程：

declare @max int
select @max = max_workers_count from …