标签: availability-groups

我正在尝试在属于可用性组的 SQL Server 2012 数据库上启用 Service Broker 并不断收到此错误消息：

无法对数据库“dbname”执行该操作，因为它涉及数据库镜像会话或可用性组。不允许对参与数据库镜像会话或可用性组的数据库执行某些操作。
ALTER DATABASE 语句失败。（Microsoft SQL Server，错误：1468）

即使尝试Trustworthy在数据库上启用也会产生相同的错误。根据这篇文章，似乎可以在为 AG 配置的数据库上启用 Service Broker。我可能会错过什么？

侦听器已配置，使用公共权限创建的端点，目标引用侦听器名称。当我尝试启用服务代理或Trustworthy通过管理控制台或 T-SQL 进行设置时发生错误。

我想补充一点，该数据库是从具有现有 Service Broker 实现的 SQL Server 2005 版本还原的。

我已经为即将推出的新“Intranet”安装并成功配置了我们的 SQL Server 2012 AlwaysOn 2 节点服务器。我已经让 AlwaysOn 运行良好，我们的 Intranet 前端服务器将使用 SharePoint 2013。问题是 SharePoint 2013 被配置为自动将数据库添加到我们的 SQL Server 2012 后端，而不是 AlwaysOn。在阅读有关此内容并联系 Microsoft MSDN 支持时，默认答案是“您必须手动查找、选择、备份然后单独添加这些新数据库，以将它们加入 AlwaysOn”。

可是等等; 这可能是一项艰巨的任务，不断检查 SQL Server 后端服务器以查看创建了哪些数据库，然后必须将它们添加到 AlwaysOn，7/24！我正在寻找一个脚本或进程来检查新数据库，以完整模式备份这些新数据库，（当然，为了被添加到 AlwaysOn），然后将这些数据库添加到 AlwaysOn，所有这些都是自动的。或者每...1-2小时运行一次？（无需用户干预）

到目前为止，我想出的是这个脚本，它实际上标识了新添加的数据库（尚未在 AlwaysOn 中），然后将它们备份到共享位置。我的下一个任务是找到那些新添加的数据库，并通过所需的各种流程，将它们添加到 AlwaysOn。我想这将涉及某种循环操作。我不是 T-SQL/脚本专家；有没有我可以访问的解决方案或脚本可以做到这一点？（自动将数据库添加到 AlwaysOn）？

请指教，我确定我不是第一个遇到这个问题的人。我在各种 Internet 站点（包括这个站点！）上看过以前的帖子，解决方案要么不正确，要么声明诸如“当然，继续编写脚本！”之类的内容。谢谢，但我需要更多细节。

再次感谢，

-艾伦

DECLARE @name VARCHAR(50) -- database name  
DECLARE @path VARCHAR(256) -- path for backup files  
DECLARE @fileName VARCHAR(256) -- filename for backup  

-- specify database backup directory
SET @path = '\\atel-web-be2\backups\'  

DECLARE db_cursor CURSOR FOR  
select name …

我正在寻找有关在 Windows Server 2012 R2 上构建 SQL Server 2016 SP1 Always On Availability Groups HADR 解决方案的一些指导。我们有一个带有主副本和辅助副本的主站点 A 和一个带有辅助副本和文件共享见证的灾难恢复 (DR) 站点 B。我们的目标是，如果站点 A 的主副本服务器 1 发生故障，则 Always On Availability Group (AG) 故障转移到站点 A 的辅助副本服务器 2，如果站点 A 的两台服务器都发生故障，则 AG 故障转移到站点 B。

我们正在尝试按照https://technet.microsoft.com/en-us/library/cc731739(v=ws.11).aspx和此图表进行节点和文件共享多数配置：

此图显示，当一个节点和“磁盘”/文件共享见证通信时，集群运行，但在我们对这种情况的测试中，由于 WSFC 的仲裁丢失，集群失败。如果我们通过禁用 vmWare 中的 NIC 一次测试一台服务器的故障，则自动 AG 故障转移会起作用，因为 SQL Server 2016 支持两个自动故障转移目标副本。但是，如果我们同时使站点 A 的两台服务器发生故障以模拟点对点网络故障或站点电源故障，则不起作用。

以下手动干预强制仲裁的方法将起作用，但它不是自动的，这是我们在理想情况下想要的：

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node –FixQuorum

ALTER AVAILABILITY GROUP SQLServerAO FORCE_FAILOVER_ALLOW_DATA_LOSS;

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode …

简单的问题（我希望！）

为什么要为 Always On AG 侦听器使用非默认端口？

我还没有找到一个很好的帖子（还）概述优点与缺点。

目前，我可以想到使用 1433 以外的其他三个原因：

• 遵循 Sql Server 安全加固指南。
• 避免端口冲突（根据https://msdn.microsoft.com/en-us/library/hh213417.aspx#SelectListenerPort）。
• 能够在网络跟踪等中更快地识别对特定 AG 的数据库调用。

有没有其他人能想到的？

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

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

虽然我们能够通过将可用性组之一移动到另一台服务器来“解决”问题，但我想知道是否可以查看哪些查询在哪个调度程序（或工作程序或任务）上运行。

通过以下查询，我可以看到有多少工人可用、正在使用和等待资源：

declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

通过以下查询，我可以看到哪些工作人员正在哪个 CPU（核心）上运行：

SELECT *
FROM  sys.dm_os_Schedulers s --> Prozessoren Kerne
JOIN sys.dm_os_workers w ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t ON t.task_address = w.task_address
WHERE s.status = 'VISIBLE ONLINE'
AND s.cpu_id = 2

有什么方法可以找到哪个 …

在AlwaysOn 可用性组(AG) 和AlwaysOn 故障转移群集实例(FCI) 的整个 MS 文档中，我看到以下模式：

1. FCI 适用于 HA 场景。
2. 与主副本位于同一位置的 AG 同步辅助副本适用于 HA 方案。
3. 位于不同数据中心的 AG 异步辅助副本用于 DR 场景。

这是讨论此问题的示例 MS 链接。

由于选项 #1 和 #2 都适用于 HA 方案，我该如何在它们之间做出决定？如果 MS 发布了 #1 和 #2 的成本和 RPO/RTO 指标，就很容易决定我想要哪个。

或者也许有一种不同的方式来理解这些选项之间的投资回报率差异。例如，也许选项 #2 最适合 VLDB，而选项 #1 最适合非常高的交易量。我不知道。

那么，DBA 用于在选项 #1 和 #2 之间进行选择的选择标准是什么？

更复杂的是，我知道选项 #1 和 #2 可以结合使用！什么时候结合这两种选择是明智的？什么时候结合这两个选项毫无意义？我知道当这些选项组合在一起时，AG 不再支持自动故障转移。这是有趣的琐事，但没有回答我的问题。

顺便说一下，我打算将我的最终解决方案供应到 Azure IaaS。如果我使用 Always On FCI，我可能会使用 Storage Spaces Direct (S2D) 创建准 SAN。

更新

我找到了两篇文章进行了比较。第一个是MS …

我们真的需要在配置了 Always On 同步更新的数据库上运行 DBCC checkdb 吗？

我相信自动页面修复机制应该识别损坏并自动修复它。

第一次打电话，长时间的听众。

我有一种情况，我需要在大约 2 个月内建立一个服务器可用性组（即将数据库移动到新服务器，重建当前服务器，并将重建的当前服务器添加到 AG）。两台服务器都是物理服务器，并且具有大致相同的规格。Windows Server 2016、SQL Server 2014。

我的想法是现在用监听器来支持 AG，这样当当前服务器被重建并添加到组中时，我们不需要添加监听器然后更新我们所有的应用程序/客户端（即这将强制两个迁移，一个到新的服务器，一个到新的监听器）。

我已经在一些测试服务器上测试了这种情况，并且它按预期工作。我也无法预见不这样做的理由，但我认为值得社区询问，因为我们正在谈论生产数据库。我的问题是有人试过这个并且有任何问题吗？有人会建议反对这个解决方案。谢谢。

我有两台服务器始终处于故障转移配置中，下面是 Windows 集群。

两台服务器需要有相同的内存吗？
我们使用大量内存的数据库之一不在 AG 中，因此理想情况下，我不想为辅助服务器提供与主服务器相同的内存，因为 - 它永远不需要运行大数据库。

我们正在运行一个带有 3 个副本的 SQL Server 2014 可用性组，一个同步（SQL2）和一个异步辅助副本。我们还配置了到同步辅助副本的只读路由。

昨晚 SQL2 从自动 Windows 更新安装重新启动。服务器重新上线，SQL Server 服务启动（延迟启动），数据库进入恢复状态。过了一会儿，事件查看器显示数据库完整性检查成功，数据库可以使用了。

数据库在 SQL Management Studio 中显示同步状态。AG 状态正常，但没有查询从数据库中获取结果。

查询被等待类型阻止：HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING。

有时，等待类型更改为“lck_m_s”等待类型，并被执行数据库启动命令的进程的 pid 阻止。我知道这与 SQL Server Enterprise 附带的快速恢复选项有关，但我不明白为什么一个简单的选择会被永远阻止。

主要问题是：SQL Server 如何显示 AG 数据库是健康的，但实际上并非如此？你认识这个问题吗？

为了解决这个问题，我们从 AG 中删除了辅助数据库，并将数据库重新加入到 AG 中，现在一切又恢复正常了。