我有一个带有多个 AG 的企业版 SQL Server 2022 集群。

其中两个 AG 将不同的实例视为主要实例。这两个 AG 都认为其次要实例是可读的，并且这样认为是正确的。

除了处于可读的辅助配置之外，没有任何东西可以使任何实例上的任何数据库变为只读。它们不是基本可用性组。

令人震惊的是：当我运行DBCC CHECKCATALOG针对可读辅助数据库的查询，同时连接到非该数据库主数据库的实例时，查询会失败，如下所示

消息 3906，级别 16，状态 8，第 1 行

无法更新数据库“DB NAME”，因为该数据库是只读的。

但DBCC CHECKDB工作得很好！

我找遍了所有地方，但没有发现任何有用的信息。

• Ola Hallengren 的 Maintenance Solution 的 GitHub 上也有同样的问题，但没有解决方案。Ola 是这方面的专家，我相信他对此非常了解，他似乎认为这是他那边的一个错误，而不是微软的错误。
• 此 git 提交表明其作者 dan-andreistefan 之前曾见过此问题。我没有找到相应的问题或 PR。Dan脱颖而出并解决了该问题。
• 除了 BAG 的限制之外，我在 SQL Server 官方文档中根本找不到有关对 AG 进行完整性检查的任何信息。它只在许可指南中。

我该如何调试它？为什么DBCC CHECKDB（它是 的超集）可以DBCC CHECKCATALOG工作，而 却DBCC CHECKCATALOG失败了？

假设我有一个企业版数据库，它具有完全默认设置，只有普通的行存储表。没有 RCSI，没有快照隔离，也没有触发器。假设不需要行版本控制。

显然，这些假设意味着我不会为行版本控制支付额外的 14 字节/行成本。但是，可读 AG 次要副本在 SNAPSHOT 隔离下运行，而 SNAPSHOT 隔离需要行版本控制。因此，如果我将数据库放入可用性组并添加可读次要副本，我的数据库的哪些副本（如果有）将开始支付 14 字节/行的行版本控制成本？如果除了可读次要副本之外，我还有一个不可读次要副本，这种情况会改变吗？如果我进行故障转移并故障恢复会怎样？

之前链接的相关文档对此没有评论。我打算自己进行实验，但众所周知，AG 很容易出错，我不想得出错误的结论。

众所周知，解码系统健康扩展事件中的 wait_resource 指针的含义是不可能的。但是，如果我在特定时间段内在该扩展事件中的所有长时间等待都报告相同的指针，那么这是否说明了什么？

我PAGELATCH_SH在这个时间段内经历了高等待时间，并认为所有指针相同的原因与此有关。我没有在这里包含 XML，因为我绝对确定它不会帮助回答这个问题。我只是想知道是否有这种情况，当它显然是一个指针时，我应该注意此扩展事件中的 wait_resource 值。

分区的好处文档列出了以下内容作为分区表的第一个性能优势

当分区列与表连接的列相同时，查询优化器可以更快地处理两个或多个分区表之间的等值连接查询。

同一页面稍后会就此主题进行更详细的说明，但这只是告诉您，连接未以完全相同方式分区的分区表不会获得与连接等效分区表相同的优化。当然，这与前面部分的说法无关；两种分区表方式之间的任何性能比较都与分区与不分区相比的优势无关。

这让我产生了一个疑问：连接等效分区表是否比连接具有相同前导聚集索引键的两个表更快？我很乐意接受实验性的答案或使用相关理论得出结论的答案。

我读过内部原理，也读过很多白皮书和博客，但我认为我没有在任何地方看到过这个问题。我对内部原理的理解让我得出结论，分区方法应该比非分区方法慢。毕竟，分区实际上所做的就是将另一个索引键放在键列表的前面。我自己的实验也发现了同样的结果。

对于 SQL Server 中的分区表，使用 min/max 函数或时存在一个臭名昭著的重大性能问题TOP。Microsoft在此处记录了此问题的解决方法。我确信此问题在 SQL Server 2022 中没有得到修复。如果给他们更多钱是一种解决方法，微软肯定会更新解决方法列表。

但是，这在 SQL Server 2022 之后有改变吗？我确信我在 2024 年看到了指向此 Connect 项目的有效链接。今天，即使在所有 Connect 项目都迁移到的现代Azure 建议中，我也找不到它。这向我表明，这个已有十年历史的错误在过去几年中发生了一些事情。

我自己无法回答这个问题，因为我无法访问 SQL Server 2025 或任何前沿的 Azure 产品，我听说 SQL Server 2025 的预览版已经发布。

假设 Windows 上的 SQL Server 2022 标准版，我根本看不到使用基本可用性组代替数据库镜像有什么好处。基本可用性组是否提供了数据库镜像没有的功能？

在这两种情况下：

• 您只能拥有 1 个主服务器和 1 个辅服务器
• 次要文件不可读
• 数据库无法以任何方式分组，从而允许它们一起进行故障转移
• 复制可以是同步的，也可以是异步的
• 自动页面修复已启用。

我发现这两个功能之间的唯一区别是基本可用性组不能升级到企业版，并且数据库镜像已被正式弃用。

我知道基本可用性组比镜像更难设置，但我只想问基本可用性组相对于数据库镜像的好处。

在 SQL Server 2016 之前，对列存储索引进行分区被认为是强制性的，因为在插入/更新/删除期间对它们采取的锁定非常严格。但是，从 SQL Server 2016 开始，对列存储索引采取的锁定强度要小得多。那么，为什么对它们进行分区仍然被认为是最佳实践呢？

我知道一个技巧，你可以通过切换分区、构建聚集行存储索引、用列存储替换该索引，然后切换回该分区来改善对齐。然而，这只是一个温和的性能优化，很少能在重建后幸存下来，而且SQL Server 2022 的排序功能在很大程度上使其变得多余。

当我查看加速数据库恢复和读取已提交快照隔离的文档时，似乎加速数据库恢复的所有缺点都与读取已提交快照隔离相同。那么假设我已经启用了读取已提交快照隔离，那么加速数据库恢复的缺点是什么？

我怀疑 Azure 中默认启用加速数据库恢复和读取已提交快照隔离并非巧合。假设是 SQL Server 2019 或 SQL Server 2022。

如果您对分区有深入的了解，那么您将完全意识到分区不是行存储索引的性能特征。但是，每当我看到对此提出论点时，就像Gail Shaw 在这里最令人信服地所做的那样，论点都取决于将非分区索引与分区索引进行比较，其中两个索引都以分区键作为其前导键。像 Gail 这样的论点基于分区消除和以您的分区键作为第一个键来寻找非分区索引之间的性能差异很小。

这些论点很有说服力，但如果分区键不是分区索引的第一个键，情况又会怎样呢？在这种情况下，我们可以获得分区消除的好处，并且我们的前导键现在可用于搜索比我们将同一索引保留为非分区时要小得多的索引。这听起来应该比将同一索引保留为非分区时的性能有所提高。

总而言之，我的问题是：如果分区列不是索引的第一个键，那么对具有多个键的索引进行分区是否会提高性能？要回答这个问题，只需要一个例子，并附上一些理论来解释为什么结果是这样的。

假设一个表只包含整数并且具有聚集列存储索引。

CREATE TABLE cci_account
(  
    AccountKey int NOT NULL,  
    UnitSold int,
    INDEX ColStore CLUSTERED COLUMNSTORE
);

那么看起来，在这样的表中，对一个列按另一个列分组求和总是很快，例如

SELECT
    AccountKey,
    SUM(UnitSold)
FROM
    cci_account
GROUP BY
    AccountKey;

为什么这么快？我对列存储架构的理解是，包含的段AccountKey不知道UnitSold其行上的值是什么。那么，SQL Server 如何能够如此快速地分组AccountKey？我无法想象任何算法可以实现这一点。

语境

我一直在尝试表分区，发现了很多惊喜。我目前正在尽可能多地阅读文档，但文档数量多得令人震惊。我想我已经读完了六份白皮书中的第二份。我还没有在任何文档中看到过这个问题。

问题

使用DROP_EXISTING = ON，似乎某些表可以就地分区。例如，我可以让它与唯一聚集索引一起工作。但是，我无法对主键执行相同的操作。本指南同意我的结论，并表示对具有主键的表进行分区需要先删除主键。这就像存在语法限制而不是功能限制。

我的问题是：什么时候可以对表进行分区而不在分区之前删除任何内容？换句话说，什么时候可以就地进行分区？

我并不是特意询问具体可以用什么方法做DROP_EXISTING。那只是我偶然发现的一种方法。

假设 SQL Server 2022。我不在乎操作是否在线。对于类似的事情，我有一个不同的问题。

演示代码

大部分内容来自 Paul White

CREATE PARTITION FUNCTION PF (integer) 
AS RANGE RIGHT
FOR VALUES 
(
    10000, 20000, 30000, 40000, 50000
);
GO
CREATE PARTITION SCHEME PS 
AS PARTITION PF 
ALL TO ([PRIMARY]);
GO
CREATE TABLE dbo.T1
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    CONSTRAINT PK_T1
    PRIMARY KEY CLUSTERED (c1, c2, c3)
);

CREATE TABLE dbo.T2
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    INDEX UIX_T2 UNIQUE CLUSTERED (c1, c2, c3)
);
GO

CREATE TABLE dbo.T3
(
    c1 integer NOT NULL,
    c2 integer NOT NULL,
    c3 integer NOT NULL,
    
    INDEX UIX_T3 UNIQUE NONCLUSTERED (c1, c2, c3)
);
GO


/* These work */
CREATE CLUSTERED INDEX UIX_T2 ON dbo.T2 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1) 
GO

CREATE NONCLUSTERED INDEX UIX_T3 ON dbo.T3 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1) 
GO

/* But I could never get the primary key to! */

在上面，您可以就地对唯一索引进行分区。但是，我还没有想到可以尝试对主键起作用的方法。我非常确定也REBUILD可以。

用简单的英语来说，“分区表和索引上的并行查询处理”和“分区表并行性”听起来是同一件事。然而，在 SQL Server 2022 中，标准版具有“分区表并行性”，但没有分区表和索引上的并行查询处理。这两个功能有何不同？

我已尽力查阅了相关文档，但尚未阅读全部白皮书。我尚未了解这两个功能的具体内容。

这个问题是本网站关于堆的评分最高的问题。它询问了堆的使用情况。但是，我认为非常大的堆（例如数千 GB）是一种特殊情况，值得单独提出一个问题。

随着聚集索引的大小增加，聚集索引惩罚也会增加，即从非聚集索引中获取剩余键所需的逻辑读取次数。堆的情况并非如此。我认为堆被不公平地忽略了，因为太多人要么从数据仓库中学习了所有的数据库设计（主键扫描，因此聚集索引，通常是一个好主意），要么从未在足够大的数据库上工作过，无法感受到拥有真正大表的代价。

这就产生了一个问题：索引良好的非常大的堆是否具有在索引良好的非常大的聚类表中找不到的实际用例？

为避免这个问题太过宽泛，我们采用以下约束。假设：

• 1 TB 堆
• 标准版盒子
• OLTP 环境（不是数据仓库）。

总的来说，这意味着您的缓冲池 RAM 限制为 128 GB，并且不会定期对主键进行大规模扫描。从磁盘读取整个堆会很麻烦，因此有关将表用作暂存表或仅备份表的任何答案都不适用。

设置

CREATE TABLE persons
(
  person_id int not null,
  name TEXT 
);

INSERT INTO persons VALUES
(1, 'Adam'),
(2, 'Paul'),
(3, 'Tye'),
(4, 'Sarah');

CREATE TABLE json_to_parse
(
  person_id int not null,
  block json
);

INSERT INTO json_to_parse VALUES
  (1, '{"size": "small", "love": "x"}'),
  (2, '{"size": "medium", "love": "xx"}'),
  (3, '{"size": "big", "love": "xxx"}');

错误

运行没有问题

SELECT
  *
FROM
  json_to_parse
CROSS JOIN LATERAL
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

但这并不

SELECT
  *
FROM
  json_to_parse,
  json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
  persons
ON
  persons.person_id = json_to_parse.person_id;

我收到错误“对表“json_to_parse”的 FROM 子句条目的引用无效”

为什么第二个查询会出错？文档说得很清楚，LATERAL对于表值函数来说，这是可选的

中出现的表函数FROM前面也可以加上关键字LATERAL，但对于函数来说，关键字是可选的；函数的参数FROM在任何情况下都可以包含对前面项提供的列的引用。

dbfiddle

我最近一直在研究 Microsoft SQL Server 的列存储索引，我开始担心我的经验与行业经验不符。列存储索引旨在使聚合变得容易。人们经常说，出于这个原因，它们非常适合事实表。

这让我感到不安。根据我的经验，事实表不是聚合的。我制作的每个事实表的列表都是“主键后跟几个维度列，后跟我们存储的有关主键的每一点信息”的形式。然后它们被转储到 PowerBI 或 ThoughtSpot 等 BI 工具中，因此非技术人员可以根据维度进行筛选并找到他们想知道的任何信息。它们可能会不时聚合，但这肯定不是表格的主要用途。我预计这样的表格会有超过 100 列。

我所描述的表设计和访问模式是否符合事实表的预期？或者我所描述的是一种完全不同类型的表，而我不知道它的名称？

我所在的服务器存在严重的阻塞问题。不是死锁，只是普通的阻塞。我们知道这是服务器的主要瓶颈。但是，他们不知道块领导者是什么，所以我不知道要调整哪些查询。我可以安装更多监控，但我注意到他们启用了查询存储。查询存储中是否有任何信息可用于查找块领导者？

据我了解，动态 SQL 是批处理的一部分。然而，当我列出sqlserver.sql_batch_completed如下内容时，

CREATE EVENT SESSION [CaptureBatch] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.sql_text)
    WHERE ([sqlserver].[database_id]>(4))) 
ADD TARGET package0.event_file(SET filename=N'CaptureBatch',max_rollover_files=(0))
WITH (STARTUP_STATE=ON);

GO

ALTER EVENT SESSION [CaptureBatch] ON SERVER 
STATE = START;

我看不到任何EXEC对该调用的调用EXEC。例如，此处的最后一行未显示在我的扩展事件日志中。

CREATE PROCEDURE [TestThis]
AS
BEGIN
    SELECT 'Test';
END

GO

EXEC (N'EXEC TestThis');

这是为什么？这些是不是EXEC不算是一批，还是我漏掉了什么？

我似乎找不到有关此事件的任何详尽文献资料，所以如果我遗漏了一些，请原谅我。

假设您有一张表：

• 读取频率如此之高以至于它几乎总是在 RAM 中。
• 非常小。
• 几乎从未改变。

将这样的表移至内存 OLTP 有什么缺点吗？我的想法是，如果它始终在内存中，那么您应该考虑使用专为驻留在内存中而设计的架构。

读取已提交快照隔离 (RCSI) 已广为人知。它可能导致性能瓶颈的主要原因是版本链太长。是否有任何等待类型表明此特定问题？或者它仅由其他等待类型显示（如果是，是什么？）。

我经常发现 的输出具有sp_spaceused误导性。数据库中所有数据的大小实际上是数据文件和日志文件的总大小。我最近发现，它在各方面都更胜一筹。它比我计划喝酒直到忘记该过程sys.database_files要好得多。sp_spacedused

这给了我一个问题：检查数据库大小时，是否有任何 提供的功能或返回值sp_spacedused无法从 获得sys.database_files？我已检查过文档，我很确定没有。