我在 SQL Server 2019 实例上有一个数据库，该数据库已启用查询存储，并且已运行多年
突然，查询存储状态返回
SELECT actual_state_desc FROM sys.database_query_store_options
去了
错误
所以我重新启用了它
ALTER DATABASE [BOB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
一切正常。然而，几个小时后，同样的事情发生了，我在同一时间在 SQL Server 日志中注意到以下消息
内部 FILESTREAM 错误：无法访问垃圾收集表。
看起来这两者是有关联的，尽管我不确定具体是如何关联的。
我们的数据库没有任何文件流文件：
SELECT COUNT(*)
FROM sys.database_files
WHERE type_desc = 'FILESTREAM'
返回 0
我再次重新启用了查询存储，但想了解这里发生了什么，以防止将来再次发生这种情况。
有人能告诉我发生了什么事以及如何解决吗？
我使用以下脚本制作生产数据库的 .bak 文件并将其保存到测试服务器，如果需要，可以在该服务器上恢复。该脚本未说明要压缩文件。运行 SQL Server 2019 Enterprise。
BACKUP DATABASE [PINK]
TO DISK = N'\\TestServer\Transfer\PINK.bak'
WITH NOFORMAT, INIT, NAME = N'PINK', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM
GO
DECLARE @backupSetId AS int
SELECT @backupSetId = position
FROM msdb..backupset
WHERE database_name = N'PINK'
AND backup_set_id = (SELECT MAX(backup_set_id)
FROM msdb..backupset
WHERE database_name = N'PINK')
IF @backupSetId IS NULL
BEGIN
RAISERROR(N'Verify failed. Backup information for database ''PINK'' not found.', 16, 1)
END
RESTORE VERIFYONLY
FROM DISK = N'\\TestServer\Transfer\PINK.bak'
WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GO
.bak测试服务器上的内存大小根据您在 Explorer 中查看的位置而定，为 162GB 或 154GB ：
.bak为了节省空间，我尝试通过添加COMPRESSION脚本来压缩：
BACKUP DATABASE [PINK]
TO DISK = N'\\TestServer\Transfer\PINK.bak'
WITH NOFORMAT, INIT, NAME = N'PINK', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10, CHECKSUM
GO
DECLARE @backupSetId AS int
SELECT @backupSetId = position
FROM msdb..backupset
WHERE database_name = N'PINK'
AND backup_set_id = (SELECT MAX(backup_set_id)
FROM msdb..backupset
WHERE database_name = N'PINK')
IF @backupSetId IS NULL
BEGIN
RAISERROR(N'Verify failed. Backup information for database ''PINK'' not found.', 16, 1)
END
RESTORE VERIFYONLY
FROM DISK = N'\\TestServer\Transfer\PINK.bak'
WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GO
执行包含的命令后COMMPRESSION，它在测试服务器上的大小相同。我检查了.ndf和.mdf文件，它们总共是 770GB 或 732GB，具体取决于您查看的位置。此外，它还包含大约 23GB 的索引信息。
.bak尽管我没有声明要这么做，但这是否已经被压缩了？
过去 3 年多来，我一直在使用 SQL Server 2016 的 SQL Server Agent 以及底层设置和脚本。它运行良好。
但是，现在，我正在将所有内容迁移到 SQL Server 2019，但相同的命令不起作用。
因此，我想知道是否有任何内容需要修改（就脚本而言），因为我正在使用 SQL Server 2019。
当我使用 SQL Server Agent 运行其他Powershell 脚本（在 Powershell 中执行某些操作）时，它可以工作。
当我现在运行 Powershell 时，收到以下错误消息：
运行 SQL Server 2019 Enterprise。我有一个 PRIMARY 文件组，但也在我创建的 Data1 文件组中添加了四个 ndf 文件。正如预期的那样，随着更多数据的添加，我不得不增加 Data1 文件组上的可用空间，但 mdf PRIMARY 文件组的大小保持相对稳定。在过去的几个月里，我不得不增加 PRIMARY 文件组中的空间。它从 5GB 开始，几周前我扩展到 10GB。再次用完空间，刚刚增加到 15GB。Data1 文件组是默认文件组。为什么 PRIMARY 文件组现在突然增长，而它不是默认文件组？每个 Data1 文件都设置为 160GB，因此 PRIMARY 仍然小得多。只是想知道是否有办法确定为什么它在过去停滞不前时会意外增长。
我有一个 2019 标准版发布者，它充当自己的分销商，在全球拥有 150 多个订阅者。有 4 个发布者，其中只有 2 个是活跃的。数据更改非常有限（每天大约 5 次写入）。订阅者都是 SQL 快速版。
我的主要问题是，一些分发代理经常决定不想正常启动；这意味着，作业在代理执行中陷入重试循环。当我查看复制监视器时，消息提示查看代理作业历史记录。代理作业历史记录指向复制监视器。
对于出现问题的代理，我已经尝试增加历史记录和输出详细程度以及将信息输出到文件，但看起来只有当代理经过初始化阶段时才会启动。
在网上阅读时，我发现了一篇关于桌面堆耗尽的旧文章，但它看起来也是指 2016 年之前的 WS（我正在运行 WS 2019），所以不确定是否真的适用。
进一步谷歌搜索没有找到任何有价值的信息。您是否知道除了向 MS 发送票据之外，调试/排除这些问题的方法，或者一些可以尝试和遵循的资源？
根据要求进行编辑，以下是我能看到的消息的复制粘贴：
复制监视器：错误消息：
由于。。。导致的结果
SELECT jh.*FROM msdb.dbo.sysjobhistory jh
INNER JOIN distribution1.dbo.MSdistribution_agents da
ON da.job_id = jh.job_id
WHERE da.name = ''
ORDER BY jh.instance_id DESC
（仅截取最新版本的截图）
在最新的 SQL Server 2019 CU、KB5037331 之后，我在我的几个 SqlServer Server 日志中反复收到以下消息：“长异步 API 调用：调度程序的调度公平性可能会受到异步 API 调用意外超过 [8 位大数字] 毫秒的影响。”
我在更新说明中看到以下变化：
“当由于底层存储的性能问题而在 Bufferpool Lazy Writer（ntdll！ZwWriteFile 系统调用）中检测到高 I/O 延迟时，添加以下日志消息：
警告长异步 API 调用：异步 API 调用意外超过 xxx 毫秒可能会影响调度程序的调度公平性。”
问题是，除了基本的 I/O 故障排除之外，我不知道该如何处理这些信息。我需要终止什么才能停止此消息？我如何确定 I/O 问题涉及哪些文件/对象以解决潜在问题？
创建尽可能简单的数据库：
CREATE DATABASE DatabaseCheck
将此数据库添加到可用性组，其中辅助数据库不可读
在主要运行中：
DBCC CHECKDB ('DatabaseCheck') WITH EXTENDED_LOGICAL_CHECKS
它成功了：
CHECKDB 在数据库“DatabaseCheck”中发现 0 个分配错误和 0 个一致性错误。DBCC 执行已完成。如果 DBCC 打印了错误消息，请联系您的系统管理员。
在辅助服务器上运行相同的 DBCC 命令。即使未发现任何错误，它仍会失败：
CHECKDB 在数据库“DatabaseCheck”中发现 0 个分配错误和 0 个一致性错误。消息 0，级别 11，状态 0，第 1 行 当前命令发生严重错误。结果（如果有）应被丢弃。
EXTENDED_LOGICAL_CHECKS可消除错误知道这是怎么回事吗？检查DBCC CHECKDB 文档没有提到 EXTENDED_LOGICAL_CHECKS 在不可读的辅助副本上不受支持。在我看来，这似乎是命令本身的一个错误。
我在命令输出中注意到的一件事是，它会检查如下统计数据：
已验证统计信息“sys.sysrscols.clst”的完整性。已验证统计信息“sys.sysrowsets.clust”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000002_00000005”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000003_00000005”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000006_00000005”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000004_00000005”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000005_00000005”的完整性。已验证统计信息“sys.sysrowsets._WA_Sys_00000008_00000005”的完整性。
在辅助运行时不存在这些
转载于：
Microsoft SQL Server 2019 (RTM-CU23) (KB5030333) - 15.0.4335.1 (X64) 2023 年 9 月 21 日 17:28:44 版权所有 (C) 2019 Microsoft Corporation 开发人员版（64 位）在 Windows Server 2019 Standard 10.0（内部版本 17763：）上
编辑：
错误日志中唯一的消息是：
Domain\user 执行的 DBCC CHECKDB (DatabaseCheck) 发现 0 个错误并修复了 0 个错误。耗时：0 小时 0 分钟 0 秒。内部数据库快照具有分割点 LSN = 00000034:000001b1:0001 和第一个 LSN = 00000034:000001af:0002。
sys.dm_server_memory_dumps 中没有最近的转储
我必须从生产数据库创建 DACPAC。我想通过 Visual Studio 2022（SQL Server 对象资源管理器和“提取 - 数据层应用程序”）来执行此操作。是否可以阻止任何进程/查询或利用更多 CPU/内存来执行此操作？
我有以下想要合并的 JSON。在我的 JSON 中，我有“kenmerken”部分，我想在其中添加更多项目。我认为这可以通过使用 JSON_MODIFY 来完成。然而，当我使用下面的语句时，它将替换项目 1、2 和 3。当我在 $.kenmerken 之前包含“append”时，它只会显示新的项目。我怎样才能将它们都包含在 kenmerken 对象中？
DECLARE @FirstJSON NVARCHAR(MAX) = N'
{
"message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
"volgnummer": 61000233530024,
"debug": null,
"kenmerken": {
"item 1": 1,
"item 2": 1,
"item 3": 1
}
}
';
DECLARE @KenmerkenToAdd NVARCHAR(MAX) = N'
{
"Item 4": false,
"Item 5": false
}
';
SET @FirstJSON = JSON_MODIFY(
@FirstJSON,
' $.kenmerken',
JSON_QUERY(@KenmerkenToAdd)
);
SELECT @FirstJSON;
会给：
{
"message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
"volgnummer": 61000233530024,
"debug": null,
"kenmerken": {
"Item 4": false,
"Item 5": false
}
}
我想要的地方：
{
"message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
"volgnummer": 61000233530024,
"debug": null,
"kenmerken": {
"Item 1": 1,
"Item 2": 1,
"Item 3": 1,
"Item 4": false,
"Item 5": false
}
}
我一直在挠头，重新阅读MSFT帮助，但我仍然无法理解sys.dm_db_index_operational_stats和sys.dm_db_index_physical_stats中的forwarded_fetch_count和forwarded_record_count之间的区别。让我用下面的例子来说明我理解观点的问题。
我运行了以下查询：
;with heaps as (
select
DB_NAME(DB_ID()) dbname, object_name ( p.object_id ) objname, sum(row_count) row_count,
DB_ID() database_id, p.object_id objectid
from
sys.dm_db_partition_stats p
join sys.objects o on o.object_id = p.object_id
WHERE
index_id = 0 and o.is_ms_shipped = 0 --and row_count > 0
group by p.object_id )
select
h.*,
forwarded_fetch_count
from heaps h
cross apply sys.dm_db_index_operational_stats(database_id, objectid, 0, null) ps
WHERE forwarded_fetch_count > 0 ORDER BY forwarded_fetch_count DESC¨
和
SELECT page_count, OBJECT_NAME(ps.object_id)
,avg_record_size_in_bytes
,avg_page_space_used_in_percent
,forwarded_record_count
FROM sys.dm_db_index_physical_stats(db_id('your_db_name'), NULL,NULL, NULL, 'DETAILED') AS ps
WHERE forwarded_record_count IS NOT NULL AND forwarded_record_count > 0
GO
这两个查询都返回了我正在调整的单个数据库中的不同表列表。第一个查询返回的表中每个表有 1000 到 100 000 条转发提取，第二个查询返回其他表集的 10 - 60 000 条转发记录计数。
作为管道胶带修复，我重建了有问题的表格。然而，在 Windows 的性能监视器中，我仍然看到大量的转发记录/秒（图表通常飙升至 100）。运行 sp_blitzfirst @seconds = 30 时，我会收到每秒大量转发的提取的警报。一旦警报是一般警报（意味着与任何数据库无关），同一语句的其他 9 个警报就会提到：“Forwarded Fetches/Sec High：TempDB Object”。根据转发的提取计数，TempDB 中的转发提取数量比 TempDB 中的转发提取数量多十倍或一百倍。
最后但并非最不重要的一点是，ISV 大量实施了触发器（我将其与 TempDB 转发提取相关）。
我的问题：