标签: sql-server-2016

我正在使用 SQL Server 2016 并遇到一种情况，即通过页锁在两个不同的表上发生死锁。据我了解，数据库从不跨表共享页面，那么从表栏中选择怎么可能阻止表foo上的更新？特别是考虑到foo没有传入或传出的 FK（它是一个独立的、隔离的表）。

这是死锁xml：

<deadlock>
<victim-list>
    <victimProcess id="process200e2c2cca8"/>
</victim-list>
<process-list>
    <process id="process200e2c2cca8" taskpriority="0" logused="528" waitresource="PAGE: 7:1:463762 " waittime="2813" ownerId="232195085" transactionname="implicit_transaction" lasttranstarted="2019-06-18T01:57:05.067" XDES="0x201379a6430" lockMode="IX" schedulerid="2" kpid="2780" status="suspended" spid="77" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2019-06-18T01:57:05.267" lastbatchcompleted="2019-06-18T01:57:05.267" lastattention="1900-01-01T00:00:00.267" clientapp="Microsoft JDBC Driver for SQL Server" hostname="EC2AMAZ-U81HN6O" hostpid="0" loginname="mydb" isolationlevel="read committed (2)" xactid="232195085" currentdb="7" currentdbname="mydb" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
        <executionStack>
            <frame procname="adhoc" line="1" stmtstart="684" stmtend="1618" sqlhandle="0x0200000068ff5415175911deba600fac1e2197ddfe8b65890000000000000000000000000000000000000000">  unknown    </frame>
            <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">  unknown    </frame>
        </executionStack>
        <inputbuf>  update foo …

我在我的系统上捕获了一个死锁，（匿名）XML 输出如下：

<deadlock>
    <victim-list>
        <victimProcess id="processf4d9233468" />
    </victim-list>
    <process-list>
        <process id="processf4d9233468" taskpriority="0" logused="0" waitresource="KEY: 6:72057594039631872 (d117f90e375f)" waittime="481" ownerId="840005340" transactionname="SELECT" lasttranstarted="2019-10-14T10:16:07.550" XDES="0xeec803db90" lockMode="S" schedulerid="16" kpid="7220" status="suspended" spid="145" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2019-10-14T10:16:07.547" lastbatchcompleted="2019-10-14T10:16:07.550" lastattention="1900-01-01T00:00:00.550" clientapp=".Net SqlClient Data Provider" hostname="MYWEBSERVER" hostpid="4512" loginname="MyOtherLogin" isolationlevel="read committed (2)" xactid="840005340" currentdb="6" currentdbname="MyDB" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
            <executionStack>
             <frame procname="MyDB.MySchema.MyProc" line="13" stmtstart="670" stmtend="9106" sqlhandle="MYSQLHANDLE">
                    SELECT p.[Col25]
                                , p.Col1
                                , pId.Col2
                                , p.Col3
                                , p.Col4
                                , p.Col5
                                , CONVERT(VARCHAR(10),p.Col6,103)
                                , a.[Col7]
                                , a.[Col8]
                                , a.[Col9]
                                , a.[Col10]
                                , a.[Col11] …

我有一个电子表格，我要导入到原始数据库中，一个 SQL Server 2016 数据库。它有所谓的“密码箱格式”的记录，显然是银行使用的。它通常看起来像这样：

Batch1 详细信息
子记录Batch2 的批处理 标题行的
另一个子记录
摘要

我在这里设置了一个小提琴。

需要注意的是：

• 第 1 列表示该行的记录“类型”。它是唯一的“通用”列。
• 每隔一列本质上会根据记录类型而变化。
• 将子记录与父记录相关联的唯一原因是它们出现在父记录之后和下一个父记录之前。ID 在行之间不共享。
• 批次后面有可变数量的子行（不可预测）。

有没有办法查询这个，以便我可以轻松地对例如一批和它的子+页脚记录进行分组？我必须做的一件事是指出页脚记录包含正确的聚合（取自子记录；包括批次的子记录数量，这是我需要验证的一部分）。

我创建了一个测试帐户来检查权限。它当前具有 Northwind 数据库的 db_datareader、db_datawriter 和 db_ddladmin 角色。但是当它尝试在 Northwind 上创建新模式时，如果它尝试将 dbo 授权为模式所有者，则创建失败，这是怎么回事？

Version: 
SQL Server Management Studio: 15.0.18183.0 
Microsoft Analysis Services Client Tools: 15.0.1487.0 
Microsoft Data Access Components (MDAC): 10.0.18362.1 
Microsoft MSXML: 3.0 6.0 
Microsoft Internet Explorer: 9.11.18362.0 Microsoft 
.NET Framework: 4.0.30319.42000 
Operating System: 10.0.18362

1. 如果我有一个数据保证永远不会更改的表，那么将 NOLOCK 提示添加到针对该表的 SELECT 查询中是否完全安全？
2. 如果我有一个表，其中某些行将被更新，但我只选择保证不会更改的行，这是否也是使用 NOLOCK 提示的完全安全的方案？

关于SET STATISTICS TIME ON并且SET STATISTICS IO ON我在 Microsoft 文档的评论中注意到，它说如下：

STATISTICS IO 为 ON 时，显示统计信息，OFF 时，不显示信息。

将此选项设置为 ON 后，所有 Transact-SQL 语句都会返回统计信息，直到该选项设置为 OFF。

这是否意味着在当前连接或整个服务器中执行的所有 Transact-SQL 语句？当我自己测试时，它似乎只在我的连接范围内。

这是我尝试运行的查询类型：

WITH CTE_Ordered AS
(
  SELECT *, ROW_NUMBER() OVER (PARTITION BY PartitionField ORDER BY DateField) AS PartitionRowId
  FROM SourceTable
),
CTE_Top1_PerPartition AS
(
  SELECT *
  FROM CTE_Ordered
  WHERE PartitionRowId = 1
),
CTE_Calculations AS
(
  SELECT AVG(NumberField1) AS NumberField1_Avg, StdDev.StdDev AS NumberField1_StdDev
  FROM CTE_Top1_PerPartition 
  CROSS JOIN
  (
     SELECT STDEV(NumberField1) AS StdDev
     FROM CTE_Top1_PerPartition 
  ) AS StdDev
  GROUP BY StdDev.StdDev
)

-- Final Select
SELECT *
FROM CTE_Calculations

每次运行最终选择时，即使 SourceTable 是孤立的并且不会更改，我的 NumberField1_StdDev 值也会更改。

我注意到如果我首先将 CTE_Top1_PerPartition 选择到临时表中，然后从该临时表运行其余的查询，那么我每次都会得到相同的 NumberField1_StdDev 结果。

我猜这与结果在 CTE_Top1_PerPartition CTE …

非聚集索引是否固有地在表上存储对主键的引用，以便它可以根据需要进行键查找？...如果是这样，将主键指定为包含列的性能是否会降低或更高创建非聚集索引？

附带问题，为什么非聚集索引默认存储主键而不是聚集索引字段来对表进行键查找？...在​​主键不是聚集索引的情况下，是不是更慢为了进行键查找，而如果它存储了聚集索引，它可以以这种方式进行查找吗？

在几天的时间里，我们的数据库服务器上的被盗内存增长缓慢。它似乎稳定在 130-140GB 左右，此时我们开始遇到更大的问题，例如内存不足错误、多秒冻结和 AG 故障转移。问题在重新启动后大约一周开始出现。我已经开始记录被盗内存的历史，如下图：

查看sys.dm_os_memory_clerks，似乎其中大部分来自针对 NUMA 节点 0 上的缓冲池记录的非页面内存：

pages_kb随着时间的推移跟踪缓冲池的总数显示页面数量随着virtual_memory_committed_kb增长而下降。（4 月 13 日，服务器重新启动以进行 Windows 更新。缓冲池在大约一个小时内填充到 400GB）

有没有人见过这种行为？

我们运行的是 SQLServer 2016 CU12 13.0.5698.0 服务器是一个 64 核的 AWS EC2 i3.16xlarge 实例。我们有许多相同大小的其他集群都显示了这个问题。我们在 32 核 i3.8xlarge 实例上也有一些集群，它们也显示了被盗内存的增长，但它们最终不会停止/抛出内存不足错误。唯一的区别（规模除外）是 64 核服务器有 2 个 NUMA 节点。

更新： MS 表示 KB4536005 中的错误修复没有被反向移植到 SQL2016。

我有一些查询需要获取 64 个以上的特定行，例如这个带有 65 个 ID 的示例。TableID 为主键，类型为 BigInt。

SELECT * FROM TableA 
        WHERE TableID IN (260905384, 260915601, 260929877, 260939625, 260939946, 261096977, 261147037, 261152934, 261163936, 261357728, 261369122, 261376714, 261454472, 261488500, 261527284, 261584786, 261619749, 261679560, 261777653, 261786639, 261795246, 261795810, 261803724, 261821199, 261824173, 261827397, 261840197, 261848595, 261874545, 261889122, 261889355, 261929793, 261953069, 262106609, 262134069, 262134088, 262339745, 262354363, 262360015, 262571936, 262586920, 262591486, 262663776, 262703601, 262746674, 262792439, 262801544, 262826561, 262933229, 262933270, 262947539, 262958110, 263021588, 263032875, 263037208, 263039292, 263045038, 263085369, 263089147, 263091427, 263097644, 263100021, 263103339, 263104396, …