标签: availability-groups

我只阅读了路由设置并且工作正常。我有一个 SQL 登录名，它使用ApplicationIntent=ReadOnly. 但是我想阻止用户访问主。

我已经看到很多关于此的主题，它们似乎都建议禁用主服务器上的登录。当我做这个连接到听众ApplicationIntent=ReadOnly失败时Login failed for user ''. Reason: The account is disabled.

我已确保帐户是相同的 SID。

谢谢你的帮助。

我们有一个看起来像这样的工作表

CREATE TABLE [dbo].[Clearing](
    [Skey] [decimal](19, 0) IDENTITY(1,1) NOT NULL,
    [BsAcctId] [int] NULL,
    [Status] [varchar](20) NULL,
     CONSTRAINT [csPk_Clearing] PRIMARY KEY CLUSTERED ( [Skey] ASC ) 
) 

像这样的覆盖索引

CREATE NONCLUSTERED INDEX [IX_Status] ON [dbo].[Clearing]
(
    [Status] ASC
)
INCLUDE ( [Skey], [BsAcctId])

我们使用这个查询来选择下一个工作

select top (1) Skey, BsAcctId, Status from Clearing with ( readpast, updlock )
  where (Clearing.Status = 'NEW')
  order by Clearing.Skey

（真实表大约有 10 列。它们都在索引 include() 子句和选择列列表中。）

执行计划非常简单。它使用 IX_Status 进行索引查找，然后使用顶级运算符。由于索引按 (status, skey) 排序，因此计划不需要排序。

该表位于 AlwaysOn 可用性组中的数据库中。该组有 2 个数据库服务器。（这是一个测试系统。）

通常这个表和查询工作得很好。所以我们去应用 Windows …

我们想要创建一个 Always On Availability 组，其中主要副本将在本地，次要副本将在 Azure VM 上。我已经研究过并且我知道这样做是可能的，但是在我发现的所有示例中，他们总是在本地也有一个辅助副本，然后第 3 个虚拟机是天蓝色的虚拟机。我们只想要 2 个副本，一个在本地，一个在 azure 上。这可能吗？

我已阅读文档以使用“添加 Azure 副本向导”，其中一个先决条件是：您的可用性组必须包含本地可用性副本。我不确定这是否意味着我必须在本地至少有一个辅助副本，还是仅意味着我必须先在本地创建可用性组，然后才添加辅助副本。

感谢您的帮助和指导！

昨天我在一个 3 节点 AlwaysOn 实例组 SQL 2014 SP3 上做一些工作，今天早上我发现有一个名BackupLocDb_1260a388-153d-4c86-a30b-0fd3feafb116为主数据库的数据库。我没有创建数据库，但我被列为所有者。

这个数据库是从哪里来的？

最初尝试使用 google，将我带到了一些 AlwaysOn 帖子，但没有明确提及数据库。我也没有在 DBA.SE 上找到它。

我可以使用 SQL Server 2017 标准版配置分布式 AG 吗？

我有一个数据库服务器设置，其中在 Windows Server 故障转移群集 (WSFC) 的三个节点上设置了三个 SQL Server 数据库实例。

负责 Windows 集群的 sysadmin 指责我手动将主集群节点设置为其他节点。

失败的可用性组是否会转移到辅助副本（包括在它们自动接管的重新启动期间）也会导致基础 Windows Server 故障转移群集切换主节点而不是将其切换回来？

这有可能成为一个分散注意力的问题，使我无法完成工作。我希望被指出正确的方向，以防止这种情况再次发生。

我们有一对 SQL 2019 Enterprise 实例，托管在 Azure 中规格和配置相同的虚拟机中。

它们用于简单的主/辅助可用性组阵列，包含跨少量 AG 的少量数据库。

单个主生产数据库利用由生产代码填充的大型（数十亿行）列存储表，并用于只读分析报告查询 - 这些查询还连接到行存储表以获取附加信息。

我们希望将只读查询卸载到只读 AG 辅助数据库上，以将负载分散到数据库上，因此我们向侦听器提供参数ApplicationIntent=ReadOnly- 这效果很好，并且针对辅助数据库发出查询。

然而，只读查询的持续时间通常比主数据库慢 10 倍。

比较相同的执行计划，我可以看到所有额外的时间都花在读取列存储表上。反复重新运行查询以确保缓存不会对辅助数据库产生任何影响。但在主要方面，我看到了与缓存相关的性能改进，重新运行时立即返回结果。另外，暂时停止AG数据同步也没有任何效果。

比较 IO 统计数据，两者相似。比较列存储对象池和行存储缓冲池中使用的内存，两者也很相似。

这里真的很茫然——我本以为辅助设备的负载要少得多，但资源相同，如果有更好的表现，而不是持续和明显更差的话。

有没有人遇到过这种情况并对我如何改善或至少证明这种情况有任何建议？

让我在这篇文章的序言中说，我在跟踪中遗漏了一些事件，但我已经添加了它们，以便下次发生这种情况时添加它们。

最近，我们在我们的环境中看到了 HADR_SYNC_COMMIT 等待类型的奇怪激增（~40k tran/s）。今天的“事件”发生在凌晨4点58分：

在继续之前，我必须补充一点，我们正在对一个大型审计表进行在线索引维护（从 OLTP 表触发器大量记录到此审计表的意义上进行审计），并且索引重建本身被阻止约 22 秒。显然，这在这个特定实例中发挥了作用，但我不太确定它与 HADR_SYNC_COMMIT 有何关系。此外，我们在白天不进行索引维护时也看到过这种情况发生。

查看跟踪，这是我在主设备上看到的：

...以及辅助设备上的所有内容：

...最后回到主要：

2023 年 12 月 1 日凌晨 4:11 左右再次发生了类似的问题，我相信我明白发生了什么。不幸的是，我没有针对这种情况的扩展事件，但我确实有一些日志记录可以描绘出更清晰的画面。从 2023-12-01 04:10:18.5430090 开始，Ola 的索引维护记录了相关数据库上索引的开始时间。Ola 报告的完成时间为 2023-12-01 04:11:13.9431563，但我相信实际 REBUILD WITH ONLINE = ON 完成的时间要早​​得多。

在查看 DPA 时，我注意到 pagelatch_sh 和 pagelatch_ex 等待时间在凌晨 4:11:03-4:11:04 出现峰值：

紧接着这些等待，同一个查询开始看到 HADR_SYNC_COMMIT，并且这些相同的等待在凌晨 4:11:13-4:11:14 完全消失，这正是 Ola 报告索引完成的时间。我的假设是索引 REBUILD 是在凌晨 4:11:03 提交的（大约需要 45 秒的工作），这导致同一数据库中的不相关 INSERT 查询只是等待所有这些日志块在辅助数据库上硬化。一旦索引完成，剩余的日志块就会立即硬化，因为它们只是微小的插入。

这是我们的一位客户提出的问题。现在我已经给出了一个通用的回应，我们将支持这一点，但是他们应该为我们提供一个测试环境。

我们的应用程序使用 .net，我们允许客户端使用数据库实例名称和用户名/密码配置我们的服务器服务（我们使用 sql-server 身份验证）。

据我所知，他们需要做的就是使用集群实例名称而不是数据库服务器的主机名配置我们的应用程序。阅读Microsoft 提供的先决条件似乎对我们来说是完全透明的。

这样对吗？我们还需要对连接字符串进行其他更改吗？还有其他问题吗？

对于 SQL Server 2012 可用性组，您只能COPY_ONLY对副本进行完整备份。您可以定期制作BACKUP LOG.

由于可以在从COPY_ONLY转储恢复数据库后恢复日志备份，我们真的需要进行完整（非COPY_ONLY）备份吗？

是的，它创建了一个新的 LSN 序列，但如果我们不做DIFFERENTIAL备份，我们需要考虑一下吗？

通过仅使用COPY_ONLY备份，我希望能够在只读副本上执行所有备份。我的 AG 是异步的，因此备份可能在主服务器之后，但这是可以接受的风险。

我做日志备份。根据我的测试，COPY_ONLY只要日志备份 LSN 比完整备份更新，我就能够恢复数据库上的任何日志备份（无论是否从 a 恢复）。完整备份会更改database_backup_lsn，COPY_ONLY不会更改，但似乎不会影响日志还原。似乎我无法恢复 DIF 备份，但我不需要那个。

dba.se Q&A里面有很好的解释：

SQL Server 2008 R2 使用事务日志还原 COPY_ONLY 完整备份

...但它没有回答我的问题。目前，我的结论是：除了第一次备份（没有它您将无法进行日志备份），COPY_ONLY如果我们不使用差异，我们只能使用备份。

我的（一般）问题是：COPY_ONLY如果我们不采取差异，我们是否真的需要非备份，如果是，为什么？