SQL 版本兼容性BOL 文章建议 SQL Server 2019 的最低兼容 JDBC 驱动程序版本为 7.4 。
旧的 JDBC 驱动程序仍然可以连接到 SQL Server 2019 吗？还是只能将列出为兼容的驱动程序版本连接到指定的 SQL Server 版本？
我们有一个跨两个数据中心设置的 4 节点 AG，使用 4 个副本和一个文件共享见证。节点 1 和 2 在数据中心 1 中，节点 3 和 4 在数据中心 2 中。节点 1 是主节点，设置为同步提交并自动故障转移到同一数据中心中的节点 2。节点 1 设置为异步提交到数据中心 2 中的节点 3 和 4。节点权重设置为节点 1 和 3（每个数据中心的主节点）为 1，节点 2 和 4 为零。
拜托，有人能告诉我如果我们在节点 1 意外关闭了 SQL Server 会发生什么行为吗？
由于节点权重，AG 是否会尝试故障转移到数据中心 2 中的节点 3，并且不会尝试故障转移到任何其他副本。还是 AG 组会因为异步而忽略节点 3，并尝试根据首选所有者列表通过自动故障转移来故障转移到第一个同步副本？
据我了解，当您重建索引时，SQL 将在数据文件末尾对页面进行排序，增加数据文件直到所有页面都已排序，然后删除旧索引，在数据文件中留下空的非连续范围。
当您重建第二个索引时会发生什么？SQL 是否执行相同的操作，增加数据文件或将第二个索引移动到第一个索引留下的旧碎片范围中？如果它使用旧的范围，那么重建会创建一个新的物理碎片索引吗？
已编辑：为什么会话报告被阻止但正在等待PAGELATCH_*，而不是LCK_M_相关的等待类型？
我以前假设 SQL Server 只会在 blocking_session_Id 列中报告阻塞会话。如果被阻止的会话正在等待逻辑锁而不是其他任何东西，例如PAGELATCH_*.
当我从 2012 system_health 扩展事件中删除死锁 XML 时，SQL Server 没有返回所有节点信息。
当我运行以下查询时
SELECT CAST(event_data.value('(event/data/value)[1]','varchar(max)') AS XML) AS DeadlockGraph
FROM (
SELECT XEvent.query('.') AS event_data
FROM ( -- Cast the target_data to XML
SELECT CAST(target_data AS XML) AS TargetData
FROM sys.dm_xe_session_targets st
INNER JOIN
sys.dm_xe_sessions s
ON s.address = st.event_session_address
WHERE name = 'system_health'
AND target_name = 'ring_buffer'
) AS Data -- Split out the Event Nodes
CROSS APPLY
TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData ( XEvent )
) AS tab ( event_data )
在我们的 Microsoft SQL Server 2008 R2 (SP3) - 10.50.6000.34 实例中，所有节点信息连同描述一起返回，即
<deadlock>
<victim-list>
<victimProcess id="process10e26bc8" />
</victim-list>
<process-list>
<inputbuf>
Proc [Database Id = 26 Object Id = 1641213047]
</inputbuf>
</process-list>
...
...
...
</deadlock>
但是，当我针对我们的 Microsoft SQL Server 2012 - 11.0.5548.0 实例运行它时，所有节点信息和描述都被删除，只返回文本，即
Proc [Database Id = 26 Object Id = 1641213047]
这可能是什么原因造成的？如果我从查询中删除该SELECT CAST(event_data.value('(event/data/value)[1]','varchar(max)')部分，则会在我们的 2012 实例中输出完整的 XML 层次结构。
我们看到非常高的 PAGELATCH_EX 和 PAGELATCH_SH 等待类型以及高 WRITELOG 等待。我已经诊断出导致 PAGELATCH 等待的查询，并且可以通过降低插入到使用 IDENTITY 值定义的繁忙集群主键的插入率来消除它们。我知道这种现象被称为最后一页插入闩锁争用。
但是我的问题是，当插入新记录时，SQL Server 是否在缓冲区页面上采用独占 PAGELATCH_EX，将记录插入缓冲区页面，将记录写入事务日志，然后详细释放独占 PAGELATCH_EX https:// www.microsoft.com/en-ie/download/details.aspx?id=26665第24页。还是先将记录写入事务日志，然后再将PAGELATCH_EX作为详细的“解决高并发上的PAGELATCH争用”插入工作负载-背景信息SQLCAT's Guide to: Relational Engine
如果记录被写入锁存机制之外的日志，那么我可以排除缓慢写入磁盘是导致高 PAGELATCH 等待的原因。但是，如果锁存器一直保持到记录被硬化记录，那么我可能应该考虑 WRITELOG。
还有多个非聚集索引会导致 PAGELATCH_* 锁存器保持更长时间，即如果一个表有一个聚集的并且多个非聚集索引是同时添加并释放到每个索引缓冲区页面的锁存器？
更新 1 在阅读了 conio-sql-server-writelog-wait幻灯片二和一般 WAL 架构之后。我现在了解到，两份白皮书中详述的“记录已修改行的日志条目”步骤是指 SQL Server 在事务日志缓存中记录更改，而不是在磁盘中记录更改。一旦事务完成或缓冲区已满，所有记录都会立即刷新到磁盘。
我们的一个发布者由三个订阅者订阅，每个订阅者都托管在自己的物理服务器上。其中两个订阅者是 2008R2 和第三个 2012。2012 年订阅者在高峰时段每天都会遇到延迟。
在运行了几天的一些扩展事件跟踪之后，我可以看到延迟与分发器处的 sp_MSget_repl_commands 执行时间缓慢有关，更具体地说，在第 724 行找到的最终选择查询“--Mini join together。只有 agent_id 和dbo.MSsubscriptions 中的 article_id 列”。此语句的执行时间可能 >= 20 分钟。
在开始将复制的命令写入命令缓冲区之前，分发器读取器线程是否等待 sp_MSget_repl_commands 的整个执行完成？或者它是否在 SP 返回后立即将复制的命令写入命令缓冲区？我看到有问题的陈述是用 OPTION (FAST 1) 暗示的，这可能表明情况就是这样。如果读取器线程在开始将复制的命令写入命令缓冲区之前确实等待 sp_MSget_repl_commands 完成，那么这可能会解释延迟，否则我不确定。还有什么明显的我可以监控的吗？
MSdistribution_history.comments 表明劫持发生在订阅者处。但是，没有复制的订阅者存储过程在 >= 100 毫秒内完成，并且没有明显的物理服务器资源争用。我已经排除了网络，因为在同一物理服务器上还有其他订阅者数据库通过同一网络填充，这些数据库没有遇到延迟。
在阅读了 The Data Loading Performance Guide之后，我仍然不确定是否有必要将 TABLOCK 表提示添加到使用聚集索引定义的空临时表中，以便获得最少的日志记录。
显然，临时表是在 TempDB 中创建的，它以 SIMPLE 恢复模式运行，所以我认为它是最小日志记录的完美候选；但是，我找不到确认它的段落。
临时表是否是最小日志记录的候选者，如果是，是否值得按照永久表的建议添加 TABLOCK 提示？
distributor.dbo.MSdistribution_history 的注释栏包含注释，例如
<stats state="2" fetch="11554" wait="214007" cmds="17898546" callstogetreplcmds="106880">
<sincelaststats elapsedtime="300" fetch="8" wait="291" cmds="1948689" cmdspersec="6495.000000" />
</stats>
状态值转换为
STATE Indication
1 Normal Log
2 Reader Thread has to WAIT for Writer
3 Writer Thread has to WAIT for Reader
评论是否告诉我读者线程正在等待作者线程，但自上次统计条目以来已经读取了 1948689 条命令。或者它告诉我读者线程正在等待作者线程，而作者线程自上次统计条目以来已经写入了 1948689 条命令？