标签: sql-server-2019

我们在 SQL 2019 企业版中使用可用性组。我们使用企业功能允许 AG 辅助节点处于只读模式，然后通过使用参数连接到侦听器来对辅助节点运行报告查询ApplicationIntent=ReadOnly。

Read Uncommitted出于锁定和性能原因，我们有一些在主数据库上使用隔离级别运行的查询。

似乎在辅助设备上，所有隔离级别都转换为 RCSI，无论指定的锁定/隔离级别如何 - 可能是因为没有可能阻止 AG 同步的锁至关重要。

是否可以在辅助数据库上以“读取未提交”的方式运行查询，这大概也可以确保不采取任何锁定，但是，在某些情况下可以执行得更好，或者对于只读辅助数据库上的查询，它始终必须是 RCSI？

据我所知，索引查找允许服务器通过查找索引快速转到所需的页面，因此无需将查询表的所有页面从磁盘读取到内存中即可获得好处。

这个问题假设：

1. 整个数据库有巨大的内存存储在内存中，
2. 被查询的表没有索引，
3. 查询是从表中选择数据，其中说rate>100
4. 带有上述 WHERE 子句的第一个查询将进行扫描，将整个表的数据页从磁盘拉入内存（因为 上没有索引rate）。

在这种情况下，我的问题是，对于使用相同 WHERE 子句 ( rate>50) 对该表进行的后续查询，SQL 引擎将对已驻留在内存中的页面执行表扫描。rate当整个表位于内存中并且不需要访问磁盘时，列上是否有索引对第二个查询有任何好处吗？

我正在 Windows Server 2019 上的 SQL Server 2019 中配置可用性组。

我们有两台 Windows 服务器 UT01 和 UT02，配置了单个网络适配器，并使用 Active Directory 域上的静态 IP 地址。

网络组为群集虚拟计算机对象分配了静态 IP 地址，UTCL，192.168.0.12。他们还为可用性组侦听器 UTAG 分配了静态 IP 地址 192.168.0.13。

服务器团队配置了 Windows Server 故障转移群集，我配置了 SQL Server 和可用性组。两个 SQL Server 都配置为命名实例；所以UT01\INS和UT02\INS是返回的名称@@SERVERNAME;

从本地子网 (192.168.0.0/24) 上的任何计算机，我可以使用 sqlcmd 连接到可用性组，如下所示：

sqlcmd -S UTAG\INS

当我运行 时PRINT @@SERVERNAME;，将返回UT01\INS或UT02\INS，具体取决于当前运行可用性组的主节点的节点。

我可以使用 sqlcmd，通过路由器从本地子网外部的网络连接到各个 SQL Server，即sqlcmd …

我有具有树结构的表（由hierarchyid列定义），我想选择特定记录的所有后代。为此，我正在使用hiearchyid.IsDescendantOf()方法。

我预计，由于我不进行简单的比较，但我正在执行操作（在本例中我调用该IsDescendantOf()方法），那么我将得到一些带有索引扫描等的可怕执行计划。

然而，SQL Server 将其优化为漂亮的小索引查找。

我很困惑为什么以及如何。

CLR 类型上的调用方法通常会被优化吗？我假设 SQL Server 将 CLR 类型视为不透明的黑匣子，因此无法发挥其魔力。（因为它也无法在本机 SQL 函数上执行此操作。）

或者这仅适用于该特定方法？（由于这些hieararchyid值是按深度优先排序的，因此我只需通过比较就可以获得类似的结果。）

演示：

CREATE TABLE dbo.HierarchyExample (
    Id INT PRIMARY KEY,
    Hieararchy HIERARCHYID NOT NULL
);

INSERT INTO dbo.HierarchyExample(Id, Hieararchy)
VALUES
(1,  hierarchyid::Parse('/1/')),
(2,  hierarchyid::Parse('/1/1/')),
(3,  hierarchyid::Parse('/1/2/')),
(4,  hierarchyid::Parse('/1/3/')),
(5,  hierarchyid::Parse('/1/3/1/')),
(6,  hierarchyid::Parse('/1/3/2/')),
(7,  hierarchyid::Parse('/1/3/3/')),
(8,  hierarchyid::Parse('/1/4/')),
(9,  hierarchyid::Parse('/1/4/1/')),
(10, hierarchyid::Parse('/1/4/2/'));

CREATE INDEX IX_HierarchyExample_Hierarchy 
ON dbo.HierarchyExample (Hieararchy);

SELECT descendant.*
FROM HierarchyExample ancestor
    INNER JOIN HierarchyExample descendant
        ON …

最近我们在对数据库进行快照时遇到错误（操作错误665）

该错误的解决方案之一是将底层磁盘类型更改为ReFS。然而，我找不到太多关于人们在 ReFS 上（而不是 NTFS）上运行 SQL Server 生产工作负载的信息。

据我了解，对于 SQL Server 2012 及更早版本 - 它使用文件流而不是稀疏文件来创建 CHECKDB 快照。ReFS 不支持，因此在 SQL Server 2012 上，ReFS 中的文件可能会导致检查 DB 时出错。

我真的很想知道是否有人在 ReFS 上运行他们的生产工作负载，以及是否有任何我们需要考虑的问题。

检查 SQL Server 2019 CTP 2.5 (15.0.1500.28) 我发现了这个新的配置选项，并在它背后徘徊。到目前为止找不到任何信息，想知道您是否知道在哪里可以找到更多信息？

我想使用聚合来构建一个简单的单维标量值 JSON 数组，如下面示例中的 LuckyNumbers 数组：

[{
    "id": 1,
    "name": "Josian",
    "LuckyNumbers": [581, 777]
}, {
    "id": 2,
    "name": "Paul",
    "LuckyNumbers": [123551, 5, 646464, 1345, 75, 76]
}, {
    "id": 3,
    "name": "Seasonique",
    "LuckyNumbers": [1]
}]

使用 Postgresql 12，您可以使用本机聚合函数（fiddle）来完成此操作

--Postgresql 12 schema
create table person (   Id int primary key,   name varchar(20) ); 
insert into person values (1,'Josian'), (2,'Paul'), (3,'Seasonique');  
create table LuckyNumbers (PersonId int references person(Id), LuckyNumber int);
insert into LuckyNumbers (PersonId, LuckyNumber) values (1,581), (1,777), (2,123551), (2,5), …

下面的查询使用 StackOverflow2010 示例数据库：

DECLARE @Id INT = 18471

SELECT c.UserId FROM dbo.Comments AS c
INNER HASH JOIN dbo.Users AS u
ON c.UserId = u.Id
AND c.UserId = @Id

使用散列连接提示，它返回以下错误：

由于此查询中定义的提示，查询处理器无法生成查询计划。在不指定任何提示且不使用 SET FORCEPLAN 的情况下重新提交查询

当我添加时它有效 OPTION(RECOMPILE)用字符串文字或替换变量。

什么可能导致这个问题？

我在用于日志记录的表上有一个聚集的列存储索引 - 仅插入（但不是批量插入）。当前的表统计是：

• 3541 百万行
• 6.6 GB 预留空间

我今天早上通过以下操作看到以下操作sp_whoisactive：

ALTER INDEX [...] ON [...].[...] 
REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);

我使用以下查询来检查row_group_id我们有多少行：

SELECT
    tables.name AS table_name,
    indexes.name AS index_name,
    partitions.partition_number,
    dm_db_column_store_row_group_physical_stats.row_group_id,
    dm_db_column_store_row_group_physical_stats.total_rows,
    dm_db_column_store_row_group_physical_stats.deleted_rows,
    dm_db_column_store_row_group_physical_stats.state_desc,
    dm_db_column_store_row_group_physical_stats.trim_reason_desc
FROM sys.dm_db_column_store_row_group_physical_stats
INNER JOIN sys.indexes
ON indexes.index_id = 
    dm_db_column_store_row_group_physical_stats.index_id
AND indexes.object_id = 
    dm_db_column_store_row_group_physical_stats.object_id
INNER JOIN sys.tables
ON tables.object_id = indexes.object_id
INNER JOIN sys.partitions
ON partitions.partition_number = 
    dm_db_column_store_row_group_physical_stats.partition_number
AND partitions.index_id = indexes.index_id
AND partitions.object_id = tables.object_id

我们3383用1048576行和很少的行来排列组，如下所示： …

我有一个报告表（大约 10 亿行）和一个很小的维度表：

CREATE TABLE dbo.Sales_unpartitioned (
    BusinessUnit    int NOT NULL,
    [Date]          date NOT NULL,
    SKU             varchar(8) NOT NULL,
    Quantity        numeric(10, 2) NOT NULL,
    Amount          numeric(10, 2) NOT NULL,
    CONSTRAINT PK_Sales_unpartitioned PRIMARY KEY CLUSTERED (BusinessUnit, [Date], SKU)
);

--- Demo data:
INSERT INTO dbo.Sales_unpartitioned
SELECT severity AS BusinessUnit,
       DATEADD(day, message_id, '2000-01-01') AS [Date],
       LEFT([text], 3) AS SKU,
       1000.*RAND(CHECKSUM(NEWID())) AS Quantity,
       10000.*RAND(CHECKSUM(NEWID())) AS Amount
FROM sys.messages
WHERE [language_id]=1033;

--- Artificially inflate statistics of demo data:
UPDATE STATISTICS dbo.Sales_unpartitioned WITH ROWCOUNT=1000000000;

--- …