我已经安装了 SQL Server 2019 RC1，但无法创建快照。当我运行快照代理时，我不断收到相同的消息：
2019-10-30 12:32:41.59 Microsoft (R) SQL Server Snapshot Agent
2019-10-30 12:32:41.59 [Assembly Version = 15.0.0.0, File Version = 15.0.1900.25]
2019-10-30 12:32:41.59 Copyright (c) 2016 Microsoft Corporation.
2019-10-30 12:32:41.59 The timestamps prepended to the output lines are expressed in terms of UTC time.
2019-10-30 12:32:41.59 User-specified agent parameter values:
2019-10-30 12:32:41.59 --------------------------------------
2019-10-30 12:32:41.59 -Publisher DB100
2019-10-30 12:32:41.59 -PublisherDB REF3_DB
2019-10-30 12:32:41.59 -Publication REF3_PDR4
2019-10-30 12:32:41.59 -Distributor DB100
2019-10-30 12:32:41.59 -DistributorSecurityMode 1
2019-10-30 12:32:41.59 -XJOBID 0xA694274CD89FAF418C8B059F22C01B85
2019-10-30 …我有一个具有以下结构的表：
ItemID int
ItemType char(1)
Language char(2)
Localization char(2)
Literal nvarchar(4000)
用于将特定的文本翻译ItemID为Literal一个。该Literal列可能包含HTML标签。对于一组特定的查询，HTML需要删除这些标记，并且因为清理是使用 SQL CLR 对数千行完成的，所以我不想在读取时执行此类操作。
所以，我添加了一个像这样的持久列：
ALTER TABLE [dbo].[table]
ADD [LiteralSanitized] AS NULLIF(CAST(LTRIM(RTRIM([dbo].[fn_Utils_RemoveAllHtmlTags] ([Literal]))) AS NVARCHAR(4000)), '') PERSISTED;
该表只有一个索引（主键），定义如下：
ItemID, ItemType, Language, Localization
所以查询速度更快，但我看到这个表有一些额外的读取：
Scan count - 2 vs 12,230
Logical reads - 3,234 vs 43,472
这可能是正常的，因为现在我因为该列而读取了更多数据。所以，我添加了以下索引：
(ItemID ASC, ItemType ASC, Language ASC, Localization ASC) INCLUDE ([LiteralSanitized])
但它不被引擎使用。所以，我尝试强制引擎使用它：
UPDATE #temp
SET [QuestionText] = PSGQ.[LiteralSanitized]
FROM #temp PQD
INNER JOIN [dbo].[table_with_translations] …无论 where 子句如何；
当表是堆（没有聚集索引）时，选择查询是否会使sql server锁定所有行，直到它完成读取所有行？
在具有聚集索引的表的情况下，sql server将逐一锁定行并在读取该行后立即释放它们？
有关此主题的任何参考链接都会非常有帮助。
我们的第 3 方生产系统之一经历了重大升级，通过 sp_whoisactive，我现在看到很多查询（1 个事务深度），这些查询阻止了我读取 dm_db_missing_index_details 的任何尝试。
我尝试过设置事务隔离级别并使用 NOLOCK，但 SQL 只是当着我的面笑。
汉娜·弗农 (Hannah Vernon) 能够在这里复制这种行为。
有谁知道如何解决这个问题？
上周我们的系统遇到了一些奇怪的阻塞，Redgate Intellisense 是阻塞链的一部分，是否有其他DMV也有同样的问题？
我们有 2 个完全相同的数据库环境。第二个环境包含生产数据库的副本并在发票表中托管大约 11M 条记录。此环境的目标是用于查看特定升级查询需要多长时间才能知道是否会出现任何停机（因为表在架构更改期间被锁定）
在第二个环境中执行 add 语句时
alter table Invoice add IsVerified bit not null default(0)
查询立即退出，这很奇怪，因为里面有11M条记录。我预计至少会有一点延迟。即使是 select count(*) 也需要更长的时间。然而，在主生产数据库上，它需要更长的时间，超过 30 秒，因此我们必须将此查询计划到一个特殊的维护窗口中。执行查询时，没有任何东西阻止 SPID（使用 sp_who2 检查）
可能是什么原因，数据库的第二个副本似乎根本没有在 11M 记录数据库中添加列，而另一个主数据库无法及时完成（<30 秒）。也许一些特殊设置允许您添加默认值列而不需要写入所有记录？难道是因为我们的测试环境是Developer版而生产环境是Standard版？也许开发版中的某些特殊功能在 SQLStandard 中未激活？
select count(*) from Invoice //result: 11701200
SQL Server Execution Times:
CPU time = 2375 ms, elapsed time = 608 ms.
要添加的脚本：
alter table Invoice add IsVerified bit not null default(0)
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server …在不需要 WSFC 集群的 SQL AG（读取扩展）异步模式下，假设以下场景：
当辅助数据库启动时，它如何将其数据库与主数据库同步？这是自动还是手动过程？
我的 SQL 2019 enterprise 系统内存为 180GB，最大 SQL Server 内存配置为 160GB。
有 3 个大型数据库，每个数据库大约 450GB。其他的是较小的数据库。
当我运行以下查询时：
SELECT
databases.name AS database_name,
COUNT(*) * 8 / 1024 AS mb_used
FROM sys.dm_os_buffer_descriptors
INNER JOIN sys.databases
ON databases.database_id = dm_os_buffer_descriptors.database_id
GROUP BY databases.name
ORDER BY COUNT(*) DESC;
输出是：
Db1 83443
Db2 35665
Db3 20112
Db4 3559
Db5 2236
Tempdb 988
Msdb 670
Ssisdb 21
Master 2
Model 0
以上合计为146696=143GB。
我并行安排了 3 个代理作业，1 个作业目标 1 db（针对 db1、db2 和 db3）。该作业对一些最大的数据库表一一执行 select *。我执行 SELECT * 的所有表的总大小约为 250GB。
我知道 …
运行以下命令后，我正在查看查询的输出：SET STATISTICS IO ON
表1显示扫描计数为5，逻辑读取12197
表2显示扫描计数为0，逻辑读取80
文档说
扫描计数是在任何方向到达叶级别后开始的查找或扫描次数，以检索所有值以构建输出的最终数据集。
我正在寻找一个示例来了解此（扫描计数）对于上述输出的含义。我的困惑是，仅 5 次扫描如何实现 12197 的逻辑读取？
在我们的服务器上运行 CHECKDB 时，我们遇到了以下错误：
在文件“D:\MSSQL\Data\database1.mdf_MSSQL_DBCC34”中的偏移量 0x00021279006000 处写入时，操作系统向 SQL Server 返回错误 665（由于文件系统限制，请求的操作无法完成）。
正在运行的命令：
DBCC CHECKDB (database) WITH ALL_ERRORMSGS, NO_INFOMSGS, PHYSICAL_ONLY
设置：
生产环境中的5台服务器可用性组
测试环境中的2台服务器可用性组
这一切都发生在同一个晚上。生产服务器上的数据库相同，但测试中的数据库不同。当然，我接到电话并开始调查此事。我决定在产品中的服务器 3 上再次运行 CHECKDB，以查找失败的数据库，并且成功且没有错误。此后我们再次收到错误，但它是随机的，这让我怀疑它是否是基于活动的。根据我们的监测，该活动相当正常。
根据本文 ( https://www.mssqltips.com/sqlservertip/3008/solving-sql-server-database-physical-file-fragmentation/ )，我们使用 CONTIG -A 查看了文件碎片。mdf 文件的碎片还不错（2 和 4 个碎片）。
我在 SQL Server 2019 的一个表中有一个数据库，其中包含大量 varbinary(MAX) 重复记录。我们需要删除重复项，因此我运行了删除查询来删除重复项。数据库大小在删除语句之前没有保持不变，而是在查询完成后增加。我即将应用 DBCC SHRINKFILE(N'myDatabase', 0)，但我真的很好奇为什么数据库大小会增加。附件是我的删除查询。
DELETE from Document WHERE DocumentId in
(
SELECT t.DocumentId
FROM (
SELECT s.*,
ROW_NUMBER() OVER (PARTITION BY s.DocumentName, s.SubmitDateTime, s.DocumentType ORDER BY s.DocumentName, s.SubmitDateTime, s.DocumentType) AS [RowCount]
FROM Document s
LEFT OUTER JOIN Staging b ON s.DocumentId = b.DocumentId
LEFT OUTER JOIN RejectTable r ON s.DocumentId = r.DocID
WHERE b.DocumentId IS NULL
AND r.DocID IS NULL
AND s.SubmitDateTime IS NOT NULL
AND s.InsertDateTime IS NOT NULL
AND s.DocumentName IS NOT …