PTL_SQL's questions

按照SQL Server DAG 的手动故障转移中的步骤操作

要验证两个可用性组是否已准备好进行故障转移，请使用以下在 SQLCMD 模式下运行的 T-SQL 查询：

:CONNECT TDPRD071  
SELECT ag.name, drs.database_id, db_name(drs.database_id) as database_name,  
       drs.group_id, drs.replica_id, drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs  
INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

:CONNECT TDDR071  
SELECT ag.name, drs.database_id, db_name(drs.database_id) as database_name,  
       drs.group_id, drs.replica_id, drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs  
INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

如文章中所示，从全局主节点运行上述查询的结果屏幕截图显示了与 DAG 中每个 AG 的连接。

但是，当我在 DAG 的全局主节点上运行查询时，得到的结果仅来自与转发器的连接。因此，显示的两组结果仅来自与 AG02 的连接。

但是，如果我单独运行这两个查询（均来自全局主数据库），它们将根据情况正确连接到 AG01 或 AG02。

请问您有什么建议可以解释我为什么会出现这种行为吗？

谢谢。

我计划从 AG 中删除多个大型数据库，但没有合适的测试环境来测试我的脚本。我只有一个用于规模小得多的数据库的测试环境。

但是我计划做的是：

1. 在“对象资源管理器详细信息”中选择多个大型数据库，并编写脚本将它们移除到查询表中，然后一次性运行查询表中的脚本化 alter 语句集合。然后执行类似操作，一次性移除辅助副本中的“正在恢复”数据库。
2. 或者在对象资源管理器中选择多个大型数据库，然后在 SSMS 中单击一下即可直接删除它们。同样，在 SSMS 对象资源管理器详细信息中单击一下即可删除辅助数据库中的“正在恢复”数据库。

我担心的是，它们都是大型数据库，其中一些大约每个有 2TB，大约有 300 个。使用自动播种来添加它们。在从 AG 中删除这么多大型数据库时，我需要担心什么吗？只需单击一下即可？

请问在执行此操作时有哪些问题需要强调？

谢谢

我仅针对一个跟踪文件收到以下警报：文件“xxx.trc”不是可识别的跟踪文件。

我可以使用 fn_trace_gettable 从所有其他跟踪文件中进行选择。

删除这个 0 字节文件来停止警报是否安全？

谢谢

查看有关在 AG 上应用 SQL 补丁的 Microsoft 文档。

提到减少/最小化停机时间和数据丢失，但并未完全避免停机时间。我是否可以期望能够在没有任何停机时间的情况下应用补丁？

我将非常感激您的想法。

谢谢

我将非常感激您的建议。

我需要用两个本地副本修补 SQL 2019 可用性组环境。

我计划采取的详细措施如下：

• 将主服务器上的故障转移模式从自动更改为手动
• 首先修补辅助副本
• 将 AG 故障转移到已修补的辅助服务器
• 修补新的辅助节点（即旧的主节点）
• 故障回复至旧主服务器

对于我来说，在启动之前将主服务器上的同步提交模式更改为异步提交模式真的很重要吗？

我担心的是，所讨论的实例有 300 多个数据库，其中一些非常大。如果我将可用性模式更改为异步，那么当我完成对辅助数据库的修补并将 AG 故障转移到修补的辅助数据库时，我将需要在每个数据库上的新辅助数据库（即旧主数据库）上恢复数据移动。对于超过 300 个数据库的实例，这是一个耗时的过程。

因此我的问题是：

• 如果我能够确保任务的停机时间，并且在修补过程中没有进行任何事务，那么在不切换到异步提交模式的情况下继续执行该过程是否安全？在这种情况下，我需要做的就是更改为手动故障转移，修补辅助服务器，故障转移到修补的辅助服务器，然后修补新的辅助服务器（即旧的主服务器）并故障恢复到旧的主服务器。

此外，如果出于某种原因，我无法确保任务的停机时间，并且在修补辅助数据库时主数据库正在使用中。如果我在修补过程中将可用性模式保留为同步，是否会面临数据丢失的风险？

请提供建议。

谢谢。

请教三个问题：

• 我们能否拥有跨 3 个 WSFC 集群（即跨越 3 个 AG）的单个 DAG？

• 如果是这样，是否可以对其进行配置，使两个 AG 位于同一 Active Directory 域中，而第三个 AG 位于不同的 AD 域中？

• 如果不建议跨 3 个 AG 配置单个 DAG，是否可以跨两个不同 AD 域中的两个 AG 配置一个 DAG？

谢谢

请给我一些建议吗？我们遇到过 TEMPDB 日志已满的情况，我们无法从 SSMS 连接到 SQL 2019 AG 的主副本。但是，我们能够连接到辅助副本，并在其中启动从主副本到辅助副本的故障转移。故障转移回滚了主 tempdb 上正在进行的事务，因此无论导致日志被填满的事务是什么，都会回滚并释放日志。然后，我们能够连接到该副本并将其作为主副本进行故障恢复。

我的问题是：在每个服务器节点上重新启动 SQL 服务是否有利于避免临时日志再次填满 - 即重新创建干净的空临时数据库？

我正在尝试在分布式 AG 的 2 个 Windows 集群上创建多个 SQL 实例，每个实例都有自己的 AG（和侦听器），如下所示：

• 两个站点 - 主站点和灾难恢复站点

• 每个站点都有一个 WSFC 配置 - PrimCluster 和 DRCluster。

• PrimCluster 有两个节点 - PrimNodeA 和 PrimNodeB

• DRCluster 有两个节点 - DRNodeA 和 DRNodeB

• 每个节点都有两个 SQL AG 副本，每个副本都有一个 AG（具有自己的侦听器），如下所示：

• 在 PrimNodeA 和 B 上 - Instance1_P_AG

• 在 PrimNodeA 和 B 上 - Instance2_P_AG

• 在 DRNodeA 和 B 上 - Instance1_DR_AG

• 在 DRNodeA 和 B 上 - Instance2_DR_AG

• 两个集群之间的 DAG 配置是异步的。

• 每个本地AG都是同步可用性模式，并拥有自己的AG数据库。

• 所有辅助都是不可读的

这是我第一次在集群上使用多个 SQL 实例，每个实例在两个集群之间配置了 AG 和 DAG。

我的问题请：

• 为了创建 DAG，我是否需要为每个 AG 对创建一个 DAG，如下所示：
• Instance1_P_AG 和 Instance1_DR_AG
• Instance2_P_AG 和 Instance2_DR_AG

换句话说，我是否需要多个 DAG，还是只需 Instance1_P_AG 和 Instance1_DR_AG 之间的一个 DAG 即可覆盖每个集群中的所有实例？

另外，我希望有一篇关于 DAG 中多个 SQL 实例的文章的链接。

谢谢

是否有一种快速方法可以在整个 SQL Estate 中查找包含加密 (SQL TDE) 整个数据库或数据库表列的 SQL Server 实例？

谢谢

我使用的是 SQL 2019，已安装 SSISDB。我的客户使用导入/导出向导创建一个 SSIS 包来导入 Excel 文件，只有在我必须安装 32 位版本的 Microsoft Access Database Engine 2016 Redistributable 后才成功。

但是，当他尝试从 SQL 代理作业运行该包时，他收到以下消息：

“...描述：请求的 OLE DB 提供程序 Microsoft.ACE.OLEDB.16.0 未注册。如果未安装 64 位驱动程序，请以 32 位模式运行该包...”

我是否应该在已安装 32 位版本的同一台服务器上安装 64 位版本？我无法在 SSMS 中找到将作业配置为使用 32 位选项运行的选项。

请指教。

谢谢

请问将 SSIS、SSAS 和 SSRS 安装在与 SQL 引擎实例不同的服务器上有什么好处吗？

除了额外的许可影响之外，该决定还有其他考虑因素吗？

我希望能提供有关此方面的任何有用研究文章的链接。

谢谢

有谁知道为什么我的 SQL Server 正在侦听的端口不会记录在我的错误日志中？启用 TCP/IP 并配置默认侦听端口 1433。

我在两台服务器上有这个问题：

• 一个配置了 SQL 2008 - 我可以使用 SSMS 从管理服务器远程连接到实例。但是，我无法从我正在测试连接性的应用程序进行连接
• 另一个是 SQL 2016 - 我也可以从管理服务器和我正在测试连接的应用程序远程连接到它。

端口 1433 在两台主机上都打开 - netstat -na

我希望在我的错误日志中看到一个监听端口的条目，有人知道为什么它会丢失吗？

谢谢

我已将 SQL 2019 企业版修补到安装在 2 节点 Windows 2022 群集上的 CU18，并配置了可用性组。我一直在调查当主节点重新启动时集群节点的异常和持久行为。

行为是当主节点按预期重新启动时，自动故障转移发生在先前的辅助副本（同步提交）上，但是，重新启动的节点上的 SQL 服务需要 10 到 30 分钟才能启动。Configuration Manager 中的引擎服务在此延迟期间保持“更改挂起”状态，然后当它最终启动时，必须手动启动代理。

在延迟期间，没有产生错误日志，任务管理器中没有sql server进程，事件查看器中没有相关日志。

我在互联网上做了很多研究，但还没有发现任何有用的东西。我现在正在使用 Process Monitor 来监控延迟期间发生的情况。我发现在sql引擎服务启动之前，没有sqlservr进程被Procmon捕获。然而，我还发现，在该延迟期间捕获的大多数 sql 进程都是具有各种结果的sqlceip进程。一些结果是“NAME NOT FOUND”（Operation = RegOpenKey and Path is given）或“PATH NOT FOUND”（Operation = Create File），或“BUFFER OVERFLOW”（Operation = RegQueryValue）等以及相当多的此类结果。我还在重新启动节点之前捕获了 SQL 进程，然后所有 sqlceip 结果都是“成功”

所以，我的猜测是，在延迟期间，sqlceip 正试图做一些事情，而不是由于某些原因而不是一只快乐的兔子，因此导致了延迟。现在，因为我不太清楚如何处理这些结果，而且因为我之前看到 SQL 遥测 (sqlceip) 在 SQL FCI 中导致问题，所以我正在考虑完全删除它。我尝试在启动程序中的错误报告和使用下禁用它，但我仍然在 Procmon 中有这些进程。

请提供有关如何调查/解决此问题的任何有用建议，我将不胜感激。正如我所说，如果我知道如何做，我正在考虑完全删除/禁用 sqlceip。

谢谢

请给我一些建议。

我已经为我的 SQL 2019 可用性组配置了自动种子设定。我的两个集群节点各有 8GB RAM 和 4 个处理器。实例中较小的数据库已成功添加到 AG，没有任何问题。但是，当我尝试将其添加到 AG 时，一个30GB 的数据库不断警告数据和日志文件的可用磁盘空间不足。数据文件存储有大约 70GB 的空闲空间，日志存储大约有 74GB 的空闲空间。

我忽略该消息并继续将数据库添加到 AG，并得到如下不同的行为：

• 有时它似乎已成功添加到 AG，因为 SSMS 仪表板显示 AG 健康。然而，sys.dm_server_hadr_automatic_seeding DMV 有时在一个节点上显示播种状态为已完成（failure_state_desc = NULL），而另一个节点失败（failure_state_desc = 检查是否需要播种）。有时两个节点都失败了。

• 有几次我有一个 SQL 转储错误日志

• 有一次，它似乎成功了，但我无法在 SSMS 中刷新辅助节点连接，并得到了一个 SQL 转储错误日志

• 在所有情况下，我都发现任务管理器中的内存使用率飙升至超过 4GB。我的 SQL Server 配置的最大内存约为 5GB。

请注意，此新部署的旧系统不使用 AG 技术，它使用更小的磁盘空间来存储数据和日志文件，并在其旧版本的 SQL 上成功运行。

请问我的问题：

• 是否已知自动播种会占用大量内存和/或磁盘空间？
• 如果是这样，如果我仍然想使用自动播种，有什么办法可以解决这个问题吗？
• 我应该查看节点的规格还是最好使用手动播种？

我已经对这个问题做了很多研究，但如果有人能够提供一些建议，我将不胜感激。

谢谢

我的 SQL Server 2019 可用性组数据库中的底层物理存储需要在我的集群的一个节点上更改。

数据库文件的驱动器名称、文件路径都保持不变，没有其他变化。

作为 Windows 集群上的 AG 副本，有什么需要注意的吗？

我的计划是：

• 按原样对数据库进行完整备份（即在 AG 中，而不是删除它们）
• 关闭两个节点上的服务
• 确认我无法连接到 SSMS 中的任一节点
• 交换存储并将数据库文件从旧存储物理复制到新存储
• 启动服务

我错过了什么我应该知道的吗？

除了可用性组侦听器之外，是否还有任何其他配置的 SQL Server 侦听器对象位于 Active Directory 中？

需要授予通信端点（侦听端口 5022）连接到 SQL 服务帐户，这是在 SQL 中。应该有什么其他的“监听器”配置？

谢谢

有人可以向我解释一下吗？我的理解是我们不能在AG的次副本上运行差异备份，所以如果业务需求是需要差异备份，那么我们就不能选择我们的备份偏好作为次要。

但是，我正在使用的系统的遗留系统在 AG 数据库上运行差异备份，并且备份首选项设置为“首选辅助”。遗留系统上的 SQL 版本是 SQL 2016 SP3，我正在使用的新版本是 SQL 2019。

谢谢

尝试将数据库加入辅助副本上的 AG，我收到错误：

数据库“ABC”的远程副本尚未前滚到数据库日志的本地副本中包含的时间点。（微软 SQL 服务器，错误：1412）

我查了这个错误并按照“修复”在辅助副本上以无恢复模式恢复完整和 t-log 备份，但仍然出现错误。

这是一个 SQL 2019 安装，SQL 服务在两个副本上使用相同的组托管服务帐户运行。但是，我正在尝试将测试数据库添加到以我的 Windows 帐户登录的 AG，该帐户具有系统管理员权限。这可能是问题的原因吗？我是否需要以 gmsa 身份登录 SQL 才能将数据库添加到 AG？但是认证不是混合模式，是Windows。

请对此提供一些指导，我将不胜感激。

谢谢

我需要一些帮助。

我有一个配置了 WSFC 的 2 节点 Windows 集群（集群名称 = ABCCluster）。节点 1 名为Node1 节点 2 名为Node2

SQL 2019 实例已安装并命名为INSTANCE 可用性组已配置并命名为INSTANCE_AG 可用性组侦听器已预留并命名为AGL_INSTANCE

在故障转移集群管理器的集群事件中，出现以下错误：

集群网络名称资源无法注册一个或多个关联的 DNS 名称，因为更新安全 DNS 区域的访问被拒绝。 集群网络名称：' INSTANCE_AG_AGL_INSTANCE ' DNS 区域：'our.domain.com' 确保集群名称对象 (CNO) 被授予访问安全 DNS 区域的权限

问题 1： 那个奇怪的集群名称来自哪里，即“ INSTANCE_AG_AGL_INSTANCE ”？故障转移集群管理器中的集群名称是ABCCluster

问题 2： 预留监听器名称已附加到那个奇怪的集群名称，预留监听器与此错误消息有什么关系吗？

问题 3：就像现在一样，当我停止 Node1（以前是 AG 中的主副本）上的 SQL 服务时，AG 的自动故障转移发生在从 Node1 副本到 Node2 副本。但是，当我停止 Node2 上的服务时，它不会自动故障转移回 Node1。Node1 宁愿停留在“RESOLVING”状态一段时间，直到 SQL 服务在 Node2 上重新启动，然后 Node1 副本解析为“辅助”。所以，我只有一个单向的自动故障转移。

如果我对我做错了什么有任何想法，我将不胜感激。

谢谢

我正在尝试解决我的两个环境中的一些谜团。两者都是 SQL 2019 部署，但是一个配置了 Kerberos（即为实例和端口注册了 SPN），而另一个部署没有。我一直在尝试调查这是如何发生的，但还没有深入了解。

基本上，我想了解未来部署的要求。我应该手动创建（或请求创建）SPN 还是有一些方法可以自动创建它们？例如，它们是否可以在构建应用程序层的过程中创建？

如果有人能帮我解释一下，我将不胜感激。当然，我一直在研究有关 Kerberos 身份验证和 SPN 的所有内容，但如果有关于此特定问题的任何特定文章，我将不胜感激，请提供指向它的链接。

谢谢