我正在使用 SQL Server 2016 和 SQL Server 2019 标准版。我们有这份工作已经有一段时间了。它曾经很小，但现在它运行了几十个SELECT/DELETE语句。（语句之间没有GO分隔符。）
无论如何，我可能最终会分离这份工作，即使只是为了监控目的。但由于我们使用的是 SQL 标准版，因此我密切监视 RAM 使用情况，无法找到有关 SQL 代理作业内部分配的信息。
我有一个 SQL Server 2016 Standard 生产服务器，其中包含更多 59 个客户端数据库。
Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) - 13.0.5888.11 (X64) 2021 年 3 月 19 日 19:41:38 版权所有 (c) Windows Server 2019 Standard 10.0（内部版本 17763）上的 Microsoft Corporation 标准版（64 位）： )
此服务器使用率很高，并且在所有数据库上都启用了查询存储。我在服务器上最大的数据库大小约为 800GB。它本身也使用了大约 15% 的 I/O 子系统。
我正在使用 Brent Ozar 的 sp_blitzcache proc，并且我一直在搜索服务器上执行次数最多的查询，因为我看到 Perfmon 中每秒执行的查询数有所增加。
现在，我执行最多的查询不是用户查询。执行最多的查询是在最大数据库上的内部查询存储清理查询。
我不确定该怎么做（除了尝试启用/禁用数据库上的查询存储）。如果我这样做，我将丢失所有收集的数据。
更改跟踪配置为通过自动清理保留 2 天的数据。
您认为这些查询可能会给我的服务器带来问题吗？
有人经历过类似的事情吗？
我正在使用此版本的 SQL Server。
Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64) Feb 15 2020 01:47:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: )
这听起来可能违反直觉，但我希望我的一些工作在失败时不要发送电子邮件。
我有一个非常繁忙的服务器，当它们与其他进程陷入僵局时，一些作业会失败。我对此很好，只要大部分时间工作都能成功。
我收到了太多关于工作失败的电子邮件，所以我给自己做了一份报告，告诉我昨天失败的工作，以及它们失败的次数。
SET QUOTED_IDENTIFIER ON;
declare @Today date, @Yesterday varchar(8)
select @Today = GETDATE()
select @Yesterday = REPLACE(CONVERT(VARCHAR(10),DATEADD(day, -1, @Today),121),'-','')
;With failedJobs as
(
select job_id, step_id, COUNT(*) as Occurrences
from msdb.dbo.sysjobhistory
where run_date>=@Yesterday and run_status=0
group by job_id, step_id
)
SELECT j.name,fj.Occurrences,MAX(fj.step_id) as LastSteap
from msdb.dbo.sysjobs j
join failedJobs fj on fj.job_id=j.job_id
group by j.name, fj.Occurrences
我的问题是，即使我取消选中 SSMS 中的通知，当工作死锁时我仍然会收到电子邮件。
知道我需要禁用什么吗？我需要禁用故障安全操作员吗？如果可能的话，我想避免这种情况。
我正在使用 SQL Server 2016
Microsoft SQL Server 2016 (SP2-CU14) (KB4564903) - 13.0.5830.85 (X64) 2020 年 7 月 31 日 18:47:07 版权所有 (c) Windows Server 2012 R2 Standard 6.3 (Build 9600) 上的 Microsoft Corporation 标准版（64 位） :)
我有这个表，它有两个日期时间字段，一个 StartDate 和一个 EndDate。这是一个简化版本。
CREATE TABLE Seg (
Id int not null identity(1,1),
StartDate datetime not null,
EndDate datetime not null,
ModeType tinyint not null,
TripId int not null,
constraint Pk_Segs primary key clustered (Id))
CREATE INDEX [Ix_1] ON [dbo].Seg (ModeType, EndDate, StartDate) include (TripId)
CREATE INDEX [ix_2] ON [dbo].Seg ( [EndDate], [StartDate], [ModeType] ) INCLUDE ( TripId)
CREATE INDEX Ix_3 ON [dbo].Seg ( [StartDate], [EndDate] ) INCLUDE ( Id)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-11 14:57:33.000', '2019-11-11 19:53:28.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-11 19:53:28.000', '2019-11-11 23:29:00.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-11 23:29:00.000', '2019-11-12 05:00:00.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-12 05:00:00.000', '2019-11-13 05:00:00.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-13 05:00:00.000', '2019-11-14 05:00:00.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-14 05:00:00.000', '2019-11-14 19:23:49.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-14 19:23:49.000', '2019-11-15 05:00:00.000',1,263938)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:27:54.000', '2019-11-15 22:28:59.450',1,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:28:59.450', '2019-11-15 22:29:13.000',3,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:29:13.000', '2019-11-15 22:29:13.000',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:29:13.000', '2019-11-15 22:31:21.800',1,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:31:21.800', '2019-11-15 22:31:45.000',3,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:31:45.000', '2019-11-15 22:31:46.000',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:31:46.000', '2019-11-15 22:36:56.000',1,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:36:56.000', '2019-11-15 22:37:23.700',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:34:23.000', '2019-11-15 22:42:30.400',1,262853)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-15 22:37:23.700', '2019-11-16 01:20:36.000',3,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-16 01:20:36.000', '2019-11-16 01:20:39.750',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-16 01:20:39.750', '2019-11-16 01:20:41.000',3,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-16 01:20:41.000', '2019-11-16 01:20:42.000',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-16 01:20:42.000', '2019-11-16 01:30:09.000',1,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2019-11-16 01:30:09.000', '2019-11-16 01:31:28.150',2,262850)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-19 18:38:00.000', '2020-12-19 20:12:13.290',1,284621)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-19 20:12:13.290', '2020-12-19 20:13:30.000',3,284621)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-19 20:13:30.000', '2020-12-19 21:52:19.250',1,284621)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-19 22:05:48.000', '2020-12-19 22:08:35.450',1,284622)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-19 22:09:22.000', '2020-12-20 02:26:18.710',1,284620)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-20 02:56:58.000', '2020-12-20 05:00:00.000',1,284619)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-20 05:00:00.000', '2020-12-20 07:06:13.157',1,284619)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-23 13:49:15.000', '2020-12-23 14:05:18.577',1,284586)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-23 15:40:21.000', '2020-12-23 16:01:23.640',1,284587)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-12-23 18:08:36.000', '2020-12-23 18:15:48.300',1,284603)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 13:40:32.540', '2020-08-26 13:44:19.000',3,281725)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 13:44:19.000', '2020-08-26 13:44:49.600',1,281725)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 10:22:24.000', '2020-08-26 17:17:48.300',1,281726)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 17:39:36.000', '2020-08-26 17:42:33.600',1,281727)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 17:43:55.000', '2020-08-26 17:46:14.750',1,281728)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 18:00:21.000', '2020-08-26 18:01:18.500',1,281729)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 18:01:18.500', '2020-08-26 20:35:54.000',3,281729)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 20:35:54.000', '2020-08-26 20:51:27.960',1,281729)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 20:26:57.000', '2020-08-26 20:52:26.560',1,281730)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 17:46:46.000', '2020-08-26 21:08:10.550',1,281731)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 20:53:17.000', '2020-08-26 21:18:17.057',1,281732)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-26 21:59:01.000', '2020-08-27 04:00:00.000',1,281733)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 04:00:00.000', '2020-08-27 04:18:42.063',1,281733)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 06:51:17.000', '2020-08-27 07:43:41.857',1,281734)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 07:52:51.000', '2020-08-27 07:55:01.100',1,281735)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 08:00:06.000', '2020-08-27 09:36:30.210',1,281736)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 13:37:20.000', '2020-08-27 13:51:20.210',1,281737)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 10:51:09.000', '2020-08-27 14:26:19.077',1,281739)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 14:26:19.077', '2020-08-27 14:30:44.000',3,281739)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 14:19:13.000', '2020-08-27 14:31:42.510',1,281738)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 14:30:44.000', '2020-08-27 14:39:14.127',1,281739)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-27 14:47:25.000', '2020-08-27 14:52:59.150',1,281740)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-25 23:03:36.000', '2020-08-27 15:08:29.000',3,281742)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 12:54:53.000', '2020-07-31 18:25:59.000',3,281565)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 18:25:59.000', '2020-07-31 18:32:30.000',3,281566)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 16:48:17.000', '2020-07-31 18:52:14.000',3,281098)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 20:37:33.000', '2020-07-31 20:45:18.850',1,280884)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 21:13:38.000', '2020-07-31 21:15:49.400',1,280885)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 21:20:55.000', '2020-07-31 21:25:23.350',1,280886)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 22:43:12.000', '2020-07-31 23:17:46.900',1,280887)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-07-31 21:39:19.000', '2020-07-31 23:47:38.030',1,280888)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 00:23:50.000', '2020-08-01 04:00:00.000',1,280889)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 04:00:00.000', '2020-08-01 04:59:16.980',1,280889)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 05:14:49.000', '2020-08-01 07:20:22.377',1,280890)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 07:39:50.000', '2020-08-01 07:42:20.650',1,280891)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 07:54:16.000', '2020-08-01 11:18:42.240',1,280892)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 11:18:42.240', '2020-08-01 11:20:43.000',3,280892)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 11:20:43.000', '2020-08-01 11:46:42.987',1,280892)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 13:35:33.000', '2020-08-01 13:44:34.950',1,280893)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 13:54:45.000', '2020-08-01 13:55:59.850',1,280894)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 13:58:03.000', '2020-08-01 14:03:40.350',1,280895)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 14:11:21.000', '2020-08-01 14:13:16.000',1,280896)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 14:28:20.000', '2020-08-01 14:36:25.740',1,280898)
INSERT INTO Seg (StartDate, EndDate, ModeType,TripId) VALUES ('2020-08-01 14:36:25.740', '2020- 08-01 14:36:27.000',3,280898)
示例表不是很大，但我实现了与生产中相同的查询计划。该表有大约 5000 万行。我们有一个查询需要很长时间才能运行的报告。
SELECT s.TripId, s.StartDate
FROM Seg s
WHERE s.StartDate <= '2020-08-01 04:00:00' AND s.EndDate > '2020-08-01 04:00:00'
AND s.ModeType in (1,2)
查询本身不会花费“那么”长的时间来执行，但是服务器非常繁忙，并且有时我会遇到来自系统的其他查询的死锁。
我希望能够删除谓词并且只有一个查找谓词，并减少读取次数，因为现在它读取超过 300 万行来检索 155 行。
这是查询计划（来自生产数据库）
我可以更改代码或数据库中的内容以使其正常工作。任何帮助，将不胜感激。我已经尝试微调索引或使用查询，但我没有得到任何结果。
************************ 更新 ************************* *****************
我试过JD提出的查询
它确实给了我一个不同的执行计划，但估计还有很长的路要走。这是查询计划。
也许查询提示会有所帮助？数据库兼容级别为 130。
我尝试使用查询提示
OPTION (FAST 100)
基数估计更好，因为我基本上告诉 SQL 期望 100 行，但读取不会改变。更新统计数据不会改变任何东西（它们每晚都会更新）。
这么大的桌子可能没有更好的结果？
******************************* 编辑 2 我的解决方案 *************** *****************
以防万一它可以帮助有同样问题的人。按照这个问题的第二个解决方案中提出的限制日期范围解决了我的问题。我还将按照 JD 的建议重新编写查询，因此我会将他的答案标记为答案。
WHERE '2020-08-01 04:00:00' BETWEEN s.StartDate AND s.EndDate AND s.StartDate >= '2020-07-01 04:00:00' AND s.EndDate <= '2020-09-01 04:00:00' ;
在过去的几个月里，我的 SQL Server 2019 服务器运行良好，但自上周五以来它开始自行停止。今天早上，我在上面安装了最新的累积更新。
这是我的版本
Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) Nov 2 2020 18:35:09 版权所有 (C) 2019 Microsoft Corporation Developer Edition (64-bit) on Windows Server 2019 Standard 10.0 (内部版本 17763：）（管理程序）
我也遇到了 SQL Server 2019 标准版 (RTM-CU8-GDR) 的问题。
每次都会创建一个小型转储。分析转储后，我可以看到内核基础异常。
这台服务器只运行 SQL Server，我的机器上没有更多运行。
在 SQL 的日志文件中，我看到在这条消息之后进行了转储。
在 Windows 事件查看器中，我只有一个错误，说 SQL 正在停止。
就在那个错误之前，我有关于 SQLException64 的树“Windows 错误报告”错误。
重新启动 SQL Server 不会改变任何东西。但是，如果我打开 SQL 管理控制台并启动 SQL 服务，它就可以正常启动。
我真的不知道在哪里检查，如何进一步诊断。
这是迷你转储文件。
2021-01-18 10:15:18.56 spid58 ex_terminator: Possible termination due to exception during stack unwinding.
2021-01-18 10:15:18.56 spid58 CImageHelper::Init () Version-specific dbghelp.dll is not used
2021-01-18 10:15:18.56 spid58 Using 'dbghelp.dll' version '4.0.5'
2021-01-18 10:15:18.56 spid58 **Dump thread - spid = 0, EC = 0x000001B929A93670
2021-01-18 10:15:18.56 spid58 ***Stack Dump being sent to E:\SQL Databases 2019\MSSQL15.SQL2019\MSSQL\LOG\SQLDump0002.txt
2021-01-18 10:15:18.56 spid58 * *******************************************************************************
2021-01-18 10:15:18.56 spid58 *
2021-01-18 10:15:18.56 spid58 * BEGIN STACK DUMP:
2021-01-18 10:15:18.56 spid58 * 01/18/21 10:15:18 spid 58
2021-01-18 10:15:18.56 spid58 *
2021-01-18 10:15:18.56 spid58 * ex_terminator - Last chance exception handling
2021-01-18 10:15:18.56 spid58 *
2021-01-18 10:15:18.56 spid58 * Input Buffer 255 bytes -
2021-01-18 10:15:18.56 spid58 * 16 00 00 00 12 00 00 00 02 00 00 00 00 00 00 00 00 00
2021-01-18 10:15:18.56 spid58 * ÿÿ çž Ð 01 00 00 00 ff ff 0a 00 02 00 00 00 e7 9e01 09 04 d0
2021-01-18 10:15:18.56 spid58 * ž 00 00 9e 01 0d 00 0a 00 a0 00 20 00 a0 00 20 00 a0 00
2021-01-18 10:15:18.56 spid58 * W A 20 00 a0 00 20 00 a0 00 20 00 a0 00 20 00 57 00 41 00
2021-01-18 10:15:18.56 spid58 * I T F O R ( 49 00 54 00 46 00 4f 00 52 00 28 00 0d 00 0a 00 a0 00
2021-01-18 10:15:18.56 spid58 * 20 00 a0 00 20 00 a0 00 20 00 a0 00 20 00 a0 00 20 00
2021-01-18 10:15:18.56 spid58 * R E C a0 00 20 00 a0 00 20 00 a0 00 20 00 52 00 45 00 43 00
2021-01-18 10:15:18.56 spid58 * E I V E c o n v 45 00 49 00 56 00 45 00 20 00 63 00 6f 00 6e 00 76 00
2021-01-18 10:15:18.56 spid58 * e r s a t i o n _ 65 00 72 00 73 00 61 00 74 00 69 00 6f 00 6e 00 5f 00
2021-01-18 10:15:18.56 spid58 * h a n d l e , s e 68 00 61 00 6e 00 64 00 6c 00 65 00 2c 00 73 00 65 00
2021-01-18 10:15:18.56 spid58 * r v i c e _ n a m 72 00 76 00 69 00 63 00 65 00 5f 00 6e 00 61 00 6d 00
2021-01-18 10:15:18.56 spid58 * e , m e s s a g e 65 00 2c 00 6d 00 65 00 73 00 73 00 61 00 67 00 65 00
2021-01-18 10:15:18.56 spid58 * _ t y p e _ n a m 5f 00 74 00 79 00 70 00 65 00 5f 00 6e 00 61 00 6d 00
2021-01-18 10:15:18.56 spid58 * e , m e s s a g e 65 00 2c 00 6d 00 65 00 73 00 73 00 61 00 67 00 65 00
2021-01-18 10:15:18.56 spid58 * _ b o d y 5f 00 62 00 6f 00 64 00 79 00 a0 00 0d 00 0a 00 a0 00
2021-01-18 10:15:18.56 spid58 * 20 00 a0 00 20 00 a0 00 20 00 a0 00 20 00 a0 00 20 00
2021-01-18 10:15:18.56 spid58 * F R O a0 00 20 00 a0 00 20 00 a0 00 20 00 46 00 52 00 4f 00
2021-01-18 10:15:18.56 spid58 * M d b o . B r o 4d 00 20 00 64 00 62 00 6f 00 2e 00 42 00 72 00 6f 00
2021-01-18 10:15:18.56 spid58 * k e r F o r m F i 6b 00 65 00 72 00 46 00 6f 00 72 00 6d 00 46 00 69 00
2021-01-18 10:15:18.57 spid58 * e l d s R e q u e 65 00 6c 00 64 00 73 00 52 00 65 00 71 00 75 00 65 00
2021-01-18 10:15:18.57 spid58 * s t M e s s a g e 73 00 74 00 4d 00 65 00 73 00 73 00 61 00 67 00 65 00
2021-01-18 10:15:18.57 spid58 * s 73 00 0d 00 0a 00 20 00 20 00 20 00 20 00 20 00 20 00
2021-01-18 10:15:18.57 spid58 * ) , 20 00 20 00 20 00 20 00 20 00 20 00 29 00 2c 00 20 00
2021-01-18 10:15:18.57 spid58 * t i m e o u t @ 74 00 69 00 6d 00 65 00 6f 00 75 00 74 00 20 00 40 00
2021-01-18 10:15:18.57 spid58 * W a i t T i m e o 57 00 61 00 69 00 74 00 54 00 69 00 6d 00 65 00 6f 00
2021-01-18 10:15:18.57 spid58 * u t ç$ Ð $ @ 75 00 74 00 00 00 e7 24 00 09 04 d0 00 00 24 00 40 00
2021-01-18 10:15:18.57 spid58 * W a i t T i m e o 57 00 61 00 69 00 74 00 54 00 69 00 6d 00 65 00 6f 00
2021-01-18 10:15:18.57 spid58 * u t f l o a t @ 75 00 74 00 20 00 66 00 6c 00 6f 00 61 00 74 00 0c 40
2021-01-18 10:15:18.57 spid58 * W a i t T i m e o 00 57 00 61 00 69 00 74 00 54 00 69 00 6d 00 65 00 6f
2021-01-18 10:15:18.57 spid58 * u t m Lí@ 00 75 00 74 00 00 6d 08 08 00 00 00 00 00 4c ed 40
2021-01-18 10:15:18.57 spid58 *
2021-01-18 10:15:18.57 spid58 *
2021-01-18 10:15:18.57 spid58 * MODULE BASE END SIZE
2021-01-18 10:15:18.57 spid58 * sqlservr 00007FF688800000 00007FF68889DFFF 0009e000
2021-01-18 10:15:18.57 spid58 * ntdll 00007FFCA0380000 00007FFCA056CFFF 001ed000
2021-01-18 10:15:18.57 spid58 * KERNEL32 00007FFC9FF10000 00007FFC9FFC2FFF 000b3000
2021-01-18 10:15:18.57 spid58 * KERNELBASE 00007FFC9CE60000 00007FFC9D0F4FFF 00295000
2021-01-18 10:15:18.57 spid58 * CRYPT32 00007FFC9D240000 00007FFC9D41BFFF 001dc000
2021-01-18 10:15:18.57 spid58 * ucrtbase 00007FFC9C450000 00007FFC9C549FFF 000fa000
2021-01-18 10:15:18.57 spid58 * MSASN1 00007FFC9C400000 00007FFC9C411FFF 00012000
2021-01-18 10:15:18.57 spid58 * ADVAPI32 00007FFC9FD10000 00007FFC9FDB2FFF 000a3000
2021-01-18 10:15:18.57 spid58 * msvcrt 00007FFC9FE70000 00007FFC9FF0DFFF 0009e000
2021-01-18 10:15:18.57 spid58 * sechost 00007FFC9D7B0000 00007FFC9D84EFFF 0009f000
2021-01-18 10:15:18.57 spid58 * pdh 00007FFC985D0000 00007FFC9861CFFF 0004d000
2021-01-18 10:15:18.57 spid58 * RPCRT4 00007FFCA0230000 00007FFCA034FFFF 00120000
2021-01-18 10:15:18.57 spid58 * NETAPI32 00007FFC97F00000 00007FFC97F16FFF 00017000
2021-01-18 10:15:18.57 spid58 * ole32 00007FFC9FBB0000 00007FFC9FD05FFF 00156000
2021-01-18 10:15:18.57 spid58 * combase 00007FFC9F380000 00007FFC9F6ADFFF 0032e000
2021-01-18 10:15:18.57 spid58 * bcryptPrimitives 00007FFC9D420000 00007FFC9D49EFFF 0007f000
2021-01-18 10:15:18.57 spid58 * GDI32 00007FFC9F9A0000 00007FFC9F9C8FFF 00029000
2021-01-18 10:15:18.57 spid58 * gdi32full 00007FFC9C550000 00007FFC9C6EBFFF 0019c000
2021-01-18 10:15:18.57 spid58 * msvcp_win 00007FFC9D4F0000 00007FFC9D58FFFF 000a0000
2021-01-18 10:15:18.57 spid58 * USER32 00007FFC9F9D0000 00007FFC9FB66FFF 00197000
2021-01-18 10:15:18.57 spid58 * win32u 00007FFC9CE40000 00007FFC9CE5FFFF 00020000
2021-01-18 10:15:18.57 spid58 * SQLOS 00007FFC92760000 00007FFC92767FFF 00008000
2021-01-18 10:15:18.57 spid58 * sqlTsEs 00007FFC8DE10000 00007FFC8E6DAFFF 008cb000
2021-01-18 10:15:18.57 spid58 * sqldk 00007FFC8B2C0000 00007FFC8B7ECFFF 0052d000
2021-01-18 10:15:18.57 spid58 * OLEAUT32 00007FFCA0030000 00007FFCA00F3FFF 000c4000
2021-01-18 10:15:18.57 spid58 * opends60 00007FFC92750000 00007FFC92758FFF 00009000
2021-01-18 10:15:18.57 spid58 * svl 00007FFC92720000 00007FFC9274CFFF 0002d000
2021-01-18 10:15:18.57 spid58 * qds 00007FFC8B0F0000 00007FFC8B21AFFF 0012b000
2021-01-18 10:15:18.57 spid58 * MSVCP140 00007FFC947A0000 00007FFC9483AFFF 0009b000
2021-01-18 10:15:18.57 spid58 * MPR 00007FFC94AF0000 00007FFC94B0AFFF 0001b000
2021-01-18 10:15:18.57 spid58 * VCRUNTIME140 00007FFC94730000 00007FFC94745FFF 00016000
2021-01-18 10:15:18.57 spid58 * sqlmin 00007FFC8E6E0000 00007FFC91720FFF 03041000
2021-01-18 10:15:18.57 spid58 * WINMM 00007FFC8B0C0000 00007FFC8B0E3FFF 00024000
2021-01-18 10:15:18.57 spid58 * WININET 00007FFC8ABD0000 00007FFC8B0B0FFF 004e1000
2021-01-18 10:15:18.57 spid58 * WS2_32 00007FFC9F8D0000 00007FFC9F93CFFF 0006d000
2021-01-18 10:15:18.57 spid58 * WINMMBASE 00007FFC8ABA0000 00007FFC8ABCCFFF 0002d000
2021-01-18 10:15:18.57 spid58 * cfgmgr32 00007FFC9D4A0000 00007FFC9D4E9FFF 0004a000
2021-01-18 10:15:18.57 spid58 * sqllang 00007FFC8B7F0000 00007FFC8DE05FFF 02616000
2021-01-18 10:15:18.57 spid58 * Secur32 00007FFC97890000 00007FFC9789BFFF 0000c000
2021-01-18 10:15:18.57 spid58 * WINHTTP 00007FFC97D90000 00007FFC97E83FFF 000f4000
2021-01-18 10:15:18.57 spid58 * secforwarder 00007FFC8AAA0000 00007FFC8AAB0FFF 00011000
2021-01-18 10:15:18.57 spid58 * ODBC32 00007FFC8AAE0000 00007FFC8AB93FFF 000b4000
2021-01-18 10:15:18.57 spid58 * bcrypt 00007FFC9D160000 00007FFC9D185FFF 00026000
2021-01-18 10:15:18.57 spid58 * WINTRUST 00007FFC9D100000 00007FFC9D158FFF 00059000
2021-01-18 10:15:18.57 spid58 * USERENV 00007FFC9C2B0000 00007FFC9C2D8FFF 00029000
2021-01-18 10:15:18.57 spid58 * profapi 00007FFC9C420000 00007FFC9C443FFF 00024000
2021-01-18 10:15:18.57 spid58 * ncrypt 00007FFC9BE50000 00007FFC9BE75FFF 00026000
2021-01-18 10:15:18.57 spid58 * AUTHZ 00007FFC9B270000 00007FFC9B2BAFFF 0004b000
2021-01-18 10:15:18.57 spid58 * XmlLite 00007FFC97F20000 00007FFC97F59FFF 0003a000
2021-01-18 10:15:18.57 spid58 * NETUTILS 00007FFC9B9B0000 00007FFC9B9BDFFF 0000e000
2021-01-18 10:15:18.57 spid58 * NTASN1 00007FFC9BE10000 00007FFC9BE4BFFF 0003c000
2021-01-18 10:15:18.57 spid58 * dhcpcsvc 00007FFC984D0000 00007FFC984EBFFF 0001c000
2021-01-18 10:15:18.57 spid58 * NSI 00007FFC9F750000 00007FFC9F757FFF 00008000
2021-01-18 10:15:18.57 spid58 * DPAPI 00007FFC9C170000 00007FFC9C179FFF 0000a000
2021-01-18 10:15:18.57 spid58 * SSPICLI 00007FFC9C280000 00007FFC9C2AEFFF 0002f000
2021-01-18 10:15:18.57 spid58 * SAMCLI 00007FFC9B6D0000 00007FFC9B6E7FFF 00018000
2021-01-18 10:15:18.57 spid58 * LOGONCLI 00007FFC9B9C0000 00007FFC9B9FFFFF 00040000
2021-01-18 10:15:18.57 spid58 * psapi 00007FFC9D5B0000 00007FFC9D5B7FFF 00008000
2021-01-18 10:15:18.57 spid58 * kernel.appcore 00007FFC9C3E0000 00007FFC9C3F0FFF 00011000
2021-01-18 10:15:18.57 spid58 * instapi150 00007FFC86B80000 00007FFC86B93FFF 00014000
2021-01-18 10:15:18.57 spid58 * CRYPTSP 00007FFC9D590000 00007FFC9D5A6FFF 00017000
2021-01-18 10:15:18.57 spid58 * rsaenh 00007FFC9B4B0000 00007FFC9B4E2FFF 00033000
2021-01-18 10:15:18.57 spid58 * CRYPTBASE 00007FFC9BD50000 00007FFC9BD5BFFF 0000c000
2021-01-18 10:15:18.57 spid58 * imagehlp 00007FFC9F6B0000 00007FFC9F6CCFFF 0001d000
2021-01-18 10:15:18.57 spid58 * gpapi 00007FFC9ADB0000 00007FFC9ADD1FFF 00022000
2021-01-18 10:15:18.57 spid58 * wkscli 00007FFC98A70000 00007FFC98A86FFF 00017000
2021-01-18 10:15:18.57 spid58 * cscapi 00007FFC93490000 00007FFC934A1FFF 00012000
2021-01-18 10:15:18.57 spid58 * sqlevn70 000001AC0BBE0000 000001AC0BF1BFFF 0033c000
2021-01-18 10:15:18.57 spid58 * CLUSAPI 00007FFC92B20000 00007FFC92C27FFF 00108000
2021-01-18 10:15:18.57 spid58 * DNSAPI 00007FFC9B8E0000 00007FFC9B9A5FFF 000c6000
2021-01-18 10:15:18.57 spid58 * IPHLPAPI 00007FFC9B8A0000 00007FFC9B8DCFFF 0003d000
2021-01-18 10:15:18.57 spid58 * RESUTILS 00007FFC92C30000 00007FFC92CCDFFF 0009e000
2021-01-18 10:15:18.57 spid58 * VERSION 00007FFC95770000 00007FFC95779FFF 0000a000
2021-01-18 10:15:18.57 spid58 * hkruntime 00007FFC82C60000 00007FFC82F32FFF 002d3000
2021-01-18 10:15:18.57 spid58 * dbghelp 00007FFC96FD0000 00007FFC971BCFFF 001ed000
2021-01-18 10:15:18.57 spid58 * hkcompile 00007FFC82420000 00007FFC8255FFFF 00140000
2021-01-18 10:15:18.57 spid58 * hkengine 00007FFC82560000 00007FFC82C55FFF 006f6000
2021-01-18 10:15:18.57 spid58 * SHLWAPI 00007FFC9F810000 00007FFC9F861FFF 00052000
2021-01-18 10:15:18.57 spid58 * ncryptprov 00007FFC94FD0000 00007FFC95029FFF 0005a000
2021-01-18 10:15:18.57 spid58 * msv1_0 00007FFC9BB00000 00007FFC9BB75FFF 00076000
2021-01-18 10:15:18.57 spid58 * NtlmShared 00007FFC9BAF0000 00007FFC9BAFCFFF 0000d000
2021-01-18 10:15:18.57 spid58 * cryptdll 00007FFC9BBF0000 00007FFC9BC04FFF 00015000
2021-01-18 10:15:18.57 spid58 * kerberos 00007FFC9BC40000 00007FFC9BD43FFF 00104000
2021-01-18 10:15:18.57 spid58 * schannel 00007FFC9B3E0000 00007FFC9B463FFF 00084000
2021-01-18 10:15:18.57 spid58 * SECURITY 000001C5C6D50000 000001C5C6D52FFF 00003000
2021-01-18 10:15:18.57 spid58 * MSCOREE 00007FFC959E0000 00007FFC95A43FFF 00064000
2021-01-18 10:15:18.57 spid58 * mscoreei 00007FFC8B220000 00007FFC8B2BBFFF 0009c000
2021-01-18 10:15:18.57 spid58 * SqlServerSpatial150 00007FFC82370000 00007FFC82411FFF 000a2000
2021-01-18 10:15:18.57 spid58 * clbcatq 00007FFC9FDC0000 00007FFC9FE61FFF 000a2000
2021-01-18 10:15:18.57 spid58 * msxml3 00007FFC82130000 00007FFC8236CFFF 0023d000
2021-01-18 10:15:18.57 spid58 * msoledbsql 00007FFC81E80000 00007FFC82122FFF 002a3000
2021-01-18 10:15:18.57 spid58 * COMDLG32 00007FFCA0100000 00007FFCA0226FFF 00127000
2021-01-18 10:15:18.57 spid58 * shcore 00007FFC9F760000 00007FFC9F807FFF 000a8000
2021-01-18 10:15:18.57 spid58 * SHELL32 00007FFC9DE80000 00007FFC9F379FFF 014fa000
2021-01-18 10:15:18.57 spid58 * windows.storage 00007FFC9C6F0000 00007FFC9CE3AFFF 0074b000
2021-01-18 10:15:18.57 spid58 * powrprof 00007FFC9C380000 00007FFC9C3DCFFF 0005d000
2021-01-18 10:15:18.57 spid58 * COMCTL32 00007FFC81DD0000 00007FFC81E78FFF 000a9000
2021-01-18 10:15:18.57 spid58 * MSOLEDBSQLR 000001C5D6F10000 000001C5D6F31FFF 00022000
2021-01-18 10:15:18.57 spid58 * dhcpcsvc6 00007FFC98A50000 00007FFC98A65FFF 00016000
2021-01-18 10:15:18.57 spid58 * sqlncli11 00007FFC81A70000 00007FFC81DC2FFF 00353000
2021-01-18 10:15:18.57 spid58 * MSVCR100 0000000064820000 00000000648F1FFF 000d2000
2021-01-18 10:15:18.57 spid58 * ualapi 00007FFC95030000 00007FFC95049FFF 0001a000
2021-01-18 10:15:18.57 spid58 * ntmarta 00007FFC9B0C0000 00007FFC9B0F0FFF 00031000
2021-01-18 10:15:18.57 spid58 * ESENT 00007FFC94CA0000 00007FFC94FC6FFF 00327000
2021-01-18 10:15:18.57 spid58 * SQLNCLIR11 000001C5D6FE0000 000001C5D7017FFF 00038000
2021-01-18 10:15:18.57 spid58 * netbios 00007FFC92840000 00007FFC9284BFFF 0000c000
2021-01-18 10:15:18.57 spid58 * sqlnclirda11 00000000644C0000 0000000064818FFF 00359000
2021-01-18 10:15:18.57 spid58 * SQLNCLIRDAR11 000001C5D7020000 000001C5D7057FFF 00038000
2021-01-18 10:15:18.57 spid58 * clr 00007FFC8A030000 00007FFC8AA1BFFF 009ec000
2021-01-18 10:15:18.57 spid58 * MSVCR120_CLR0400 00007FFC89F30000 00007FFC8A026FFF 000f7000
2021-01-18 10:15:18.57 spid58 * mscorlib.ni 00007FFC88980000 00007FFC89F10FFF 01591000
2021-01-18 10:15:18.57 spid58 * SqlAccess 00007FFC819F0000 00007FFC81A65FFF 00076000
2021-01-18 10:15:18.57 spid58 * clrjit 00007FFC86BB0000 00007FFC86CDAFFF 0012b000
2021-01-18 10:15:18.57 spid58 * BatchParser 00007FFC81430000 00007FFC81459FFF 0002a000
2021-01-18 10:15:18.57 spid58 * SRVCLI 00007FFC98530000 00007FFC98555FFF 00026000
2021-01-18 10:15:18.57 spid58 * mskeyprotect 00007FFC7DC40000 00007FFC7DC54FFF 00015000
2021-01-18 10:15:18.57 spid58 * mswsock 00007FFC9BB80000 00007FFC9BBE6FFF 00067000
2021-01-18 10:15:18.57 spid58 * ntdsapi 00007FFC95200000 00007FFC95227FFF 00028000
2021-01-18 10:15:18.57 spid58 * DSPARSE 00007FFC95E90000 00007FFC95E9CFFF 0000d000
2021-01-18 10:15:18.57 spid58 * rasadhlp 00007FFC96B60000 00007FFC96B69FFF 0000a000
2021-01-18 10:15:18.57 spid58 * fwpuclnt 00007FFC98900000 00007FFC98978FFF 00079000
2021-01-18 10:15:18.57 spid58 * ncryptsslp 00007FFC7DC90000 00007FFC7DCB3FFF 00024000
2021-01-18 10:15:18.57 spid58 * xpsqlbot 00007FFC81750000 00007FFC81759FFF 0000a000
2021-01-18 10:15:18.57 spid58 * xpstar 00007FFC816D0000 00007FFC81741FFF 00072000
2021-01-18 10:15:18.57 spid58 * SQLSCM 00007FFC819A0000 00007FFC819B3FFF 00014000
2021-01-18 10:15:18.57 spid58 * xpstar 000001C75A220000 000001C75A22CFFF 0000d000
2021-01-18 10:15:18.57 spid58 * SAMLIB 00007FFC971C0000 00007FFC971E2FFF 00023000
2021-01-18 10:15:18.57 spid58 * xplog70 00007FFC987F0000 00007FFC98805FFF 00016000
2021-01-18 10:15:18.57 spid58 * xplog70 000001C75A340000 000001C75A343FFF 00004000
2021-01-18 10:15:18.57 spid58 * Sort00060101 00007FFC972A0000 00007FFC972B2FFF 00013000
2021-01-18 10:15:18.57 spid58 * System.ni 00007FFC87BB0000 00007FFC887F3FFF 00c44000
2021-01-18 10:15:18.57 spid58 * System.Core.ni 00007FFC86130000 00007FFC86B7FFFF 00a50000
2021-01-18 10:15:18.57 spid58 * System.Data 00007FFC7F8A0000 00007FFC7FC07FFF 00368000
2021-01-18 10:15:18.57 spid58 * System.Transactions 00007FFC7F640000 00007FFC7F68EFFF 0004f000
2021-01-18 10:15:18.57 spid58 * System.Security.ni 00007FFC7AE00000 00007FFC7AEF2FFF 000f3000
2021-01-18 10:15:18.57 spid58 * System.Xml.ni 00007FFC80580000 00007FFC80E0BFFF 0088c000
2021-01-18 10:15:18.57 spid58 * wldp 00007FFC9BDE0000 00007FFC9BE04FFF 00025000
2021-01-18 10:15:18.57 spid58 * System.Configuration.ni 00007FFC7F770000 00007FFC7F89AFFF 0012b000
2021-01-18 10:15:18.57 spid58 *
2021-01-18 10:15:18.57 spid58 * P1Home: 0000000000000008:
2021-01-18 10:15:18.57 spid58 * P2Home: 0000FFFF00001FA8:
2021-01-18 10:15:18.57 spid58 * P3Home: 00000000000000FE:
2021-01-18 10:15:18.57 spid58 * P4Home: 00007FFC9C45A56F: 5F00000080C48148 42850F04A8C35D5B F68545D78BFFFFFF 4B8BFFFFFF378E0F 08408B49078B4D28 0490840F10403949
2021-01-18 10:15:18.57 spid58 * P5Home: 000000391D7F6330: 0000000000000005 000000391D7F62C0 0000000000000000 00007FFC8D5E151C 000000391D7F6AD8 0000000000000032
2021-01-18 10:15:18.57 spid58 * P6Home: 000000391D7F6270: 000001B929A93670 000000391D7F6BE0 000001B929A93670 00007FFC9C45A2F1 0048000000310020 00007FFC9C5095A8
2021-01-18 10:15:18.57 spid58 * ContextFlags: 000000000010004F:
2021-01-18 10:15:18.57 spid58 * MxCsr: 0000000000001FA8:
2021-01-18 10:15:18.57 spid58 * SegCs: 0000000000000033:
2021-01-18 10:15:18.57 spid58 * SegDs: 000000000000002B:
2021-01-18 10:15:18.57 spid58 * SegEs: 000000000000002B:
2021-01-18 10:15:18.57 spid58 * SegFs: 0000000000000053:
2021-01-18 10:15:18.57 spid58 * SegGs: 000000000000002B:
2021-01-18 10:15:18.57 spid58 * SegSs: 000000000000002B:
2021-01-18 10:15:18.57 spid58 * EFlags: 0000000000000202:
2021-01-18 10:15:18.57 spid58 * Rax: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * Rcx: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * Rdx: 00009C29FF1CBC79:
2021-01-18 10:15:18.57 spid58 * Rbx: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * Rsp: 000000391D7F6990: 000000391D7F6BE0 0000000000000000 000000391D7F6BE0 000001B929A93670 00000000000042AC 0000000000000000
2021-01-18 10:15:18.57 spid58 * Rbp: 000001B929A93670: 000001B929A93670 000001B929A91D80 0000000000000000 0000000000000000 0000000000000000 0000000000000002
2021-01-18 10:15:18.57 spid58 * Rsi: 000000391D7F6BE0: 000001AC0B084110 00007FFC8B2C863C 0000000000000001 0000000000000001 000001B959D02160 0000000000000000
2021-01-18 10:15:18.57 spid58 * Rdi: 000001B929A93670: 000001B929A93670 000001B929A91D80 0000000000000000 0000000000000000 0000000000000000 0000000000000002
2021-01-18 10:15:18.57 spid58 * R8: 00007FFC9C45A2F1: 4100000540C48148 C35D5F5D415E415F F6854D2A74E4854D 0679DB85FF339D74 8B4893EB3F894166 850FC63B49582444
2021-01-18 10:15:18.57 spid58 * R9: 0048000000310020:
2021-01-18 10:15:18.57 spid58 * R10: 00007FFC9C5095A8: 0000003030302B65 6156746553736C46 000000000065756C 616974696E496F52 00000000657A696C 0000000000000009
2021-01-18 10:15:18.57 spid58 * R11: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * R12: 000000000000002F:
2021-01-18 10:15:18.57 spid58 * R13: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * R14: 00007FFC8B4AA110: 0074005F00780065 0069006D00720065 006F00740061006E 0020002D00200072 007400730061004C 0061006800630020
2021-01-18 10:15:18.57 spid58 * R15: 0000000000000000:
2021-01-18 10:15:18.57 spid58 * Rip: 00007FFC9CE996C9: 8C8B480000441F0F CC3348000000C024 C481480004E822E8 246483C3000000D8 CCCCCCCCD0EB0038 CCCCCCCCCCCCCCCC
2021-01-18 10:15:18.57 spid58 * *******************************************************************************
2021-01-18 10:15:18.57 spid58 * -------------------------------------------------------------------------------
2021-01-18 10:15:18.57 spid58 * Short Stack Dump
2021-01-18 10:15:18.58 spid58 00007FFC9CE996C9 Module(KERNELBASE+00000000000396C9)
2021-01-18 10:15:18.58 spid58 00007FFC8C7D6C1E Module(sqllang+0000000000FE6C1E)
2021-01-18 10:15:18.58 spid58 00007FFC8C7DABAA Module(sqllang+0000000000FEABAA)
2021-01-18 10:15:18.59 spid58 00007FFC8BB7D959 Module(sqllang+000000000038D959)
2021-01-18 10:15:18.59 spid58 00007FFC8B31061F Module(sqldk+000000000005061F)
2021-01-18 10:15:18.60 spid58 00007FFC9C4BDE58 Module(ucrtbase+000000000006DE58)
我在这里添加了我的转储和 WinDbg lmv 文本的输出：https ://www.dropbox.com/sh/fkcsdrb7iu5b1oi/AACa9VMgZ4CWzyhnLNL7W0Saa?dl=0
更新：禁用代理解决了这个问题。但是，当我们在生产中使用代理时，我不能保持这种方式。我想我别无选择，只能就此联系微软。
我正在使用 Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64) Feb 15 2020 01:47:30 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3（构建 9600：）
我在一个 2.5 TB 的数据库上有一些非常大的表（这些表本身可以超过 700GB）。
我一直在使用一些脚本进行索引维护。现在我正在做：
它在大多数情况下都可以正常工作，但对于我的 700gb 或更大的表，我认为 10% 将是一个很难达到的百分比。我想知道我是否应该降低那些大桌子的百分比，或者将它留在那个阈值是否可以。
我必须补充一点，我的服务器有 SSD 驱动程序，但只有 128 GB 的 RAM，因为它是标准版。因此，在大型查询（如报告）的情况下，表不可能适合 RAM，它必须扫描/查找索引。
我不想因为碎片而遇到 665 错误文件系统限制。 https://learn.microsoft.com/en-ie/troubleshoot/sql/admin/1450-and-665-errors-running-dbcc （我开始向数据库添加文件组以避免该错误，因为我' m 偶尔在属于主文件组的那些大表上使用它。）
那么我应该对非常大的表进行索引维护的自定义百分比吗？还是应该没问题？
我正在使用 Microsoft SQL Server 2016 (SP2-CU11) (KB4527378) - 13.0.5598.27 (X64) Nov 27 2019 18:09:22 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2标准 6.3（内部版本 9600：）
此服务器位于 SSD 驱动器上，最大内存为 128 GB。CostTheshold for Parallelism 是 70，MaxDegree of Parallelism 是 3。
我有一个“Trips”表，它被 23 个外键和 ON DELETE CASCADE 选项引用。
这个表本身并没有那么大（530 万行，1.3 GB 的数据）。但是在 23 个引用的表中，有两个表非常大（超过 10 亿行，每个 54 和 69 GB）。
问题是当我们尝试删除“Trips”表中的少量行（比如说 4 行）时，SQL 估计要删除这么多行，它需要 10gb 的 RAM，估计数百万行将被删除返回，并锁定表。一切都停止，其他查询阻塞，应用程序超时。
以下是 1 个删除语句的主表和行数：
表 EventConditions 和 ProfileRanges 各有超过 10 亿行。
这是计划缓存：https ://www.brentozar.com/pastetheplan/?id=HJNg5I0BU
当我查看 SentryOne 计划资源管理器时，我可以看到 SQL 正在读取整个表，即使“表假脱机”随后过滤并仅保留 2012 行 ProfileRanges 和 EventConditions 大致相同。
当我使用 Brent Ozar 的 sp_blitzCache 过程查看查询的内存授予时，我可以看到该查询要求大约 10gb 的 RAM。
之后，查询要么等待 SOS_SCHEDULER_YIEL（因此等待 4ms 后轮到使用 CPU）或 MEMORY_ALLOCATION_EXT。程序超时并失败。
我能做些什么来完成这项工作？
我正在考虑的一件事是删除两个最大表上的外键并在而不是触发器中删除它们的行。但我不喜欢使用触发器而不是外键来强制数据库一致性。
任何建议或帮助将不胜感激
ProfileRanges 的主键是
EventConditions 的主键是
我正在使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 （构建 9600：）
该数据库的大小约为 870 GB。它是 SQL 标准，我在服务器上有 128 GB 的 RAM。该数据库位于 SSD 驱动器上。数据文件与日志文件位于不同的驱动器上，并且 Tempdb 也有自己的 SSD 驱动器。服务器平均每秒大约 1200 个查询，它可以高达 2000 个查询/秒。重新编译保持在较低水平，每秒只有 1 到 8 次。页面预期寿命不错，平均为 61 分钟。
服务器有 6 个物理核心 + 超线程。
我们在一个有数千台设备连接并尝试使用跟踪键同步更改的系统上大量使用 SQL Server 的更改跟踪。
它通常运行良好，但随后，服务器的锁存器会不时地飙升，从 0 毫秒到平均 60677 毫秒。
当我检查正在运行的查询时，我只能看到同步查询，全部被阻止，带有“PAGELATCH_UP”，所有尝试访问更改跟踪表，超过 300 个查询被阻止。
我有几个问题：
这些是我的更改跟踪表大小。我的查询阻塞的表是前三个表，只有几 mb 的数据。
他们都在等待同一个waitresource。
Waitresource 2:4:88968 在 tempdb 中。但是 tempdb 只负责大约 9% 的服务器写入和 6% 的读取。
但是我的查询不使用 tempdb，所以我猜是因为内部更改跟踪的工作方式？这是我的查询
DECLARE @Id INT; SET @Id = (SELECT Id FROM Users WHERE No=@No);
SELECT DISTINCT lh.Key1
FROM (
SELECT Key1 FROM CHANGETABLE(CHANGES dbo.Table1, @TrackingKey) AS CT
UNION ALL
SELECT Key1
FROM dbo.Table2 lhd
INNER JOIN (SELECT Key2 FROM CHANGETABLE(CHANGES dbo.Table2, @TrackingKey) AS CT) AS CTLHD ON(CTLHD.Key2=lhd.Key2)
UNION ALL
SELECT Key1
FROM CHANGETABLE(CHANGES dbo.Table3, @TrackingKey) AS CT
) AS L
JOIN dbo.Table1 lh ON lh.Key1 = L.Key1
WHERE lh.Id = @Id AND lh.Date BETWEEN @StartUtc AND @EndUtc
我的 tempdb 有 10 个文件，它们的大小相同。
我通常最终使客户端恢复正常的做法是将其置于停机时间，然后逐渐将其恢复，以便所有移动设备逐渐同步。但是我们的系统是关键任务，这不是一个长期的解决方案。
我一直在考虑的另一个解决方案是改变系统处理更改跟踪查询的方式。让移动设备与“自制”表同步，并用来自更改跟踪的单个服务读取更改填充此表。这样，我会将并发查询限制在更改跟踪表中，但恐怕我只会将问题转移到自制表中。
对此有什么想法吗？任何帮助将不胜感激。
编辑：头部阻滞剂
我试图确定谁是拦路者以及它在等待什么，但这是一项艰巨的任务。看来我有很多“头脑障碍者”。
所有查询都运行相同的 SELECT，几乎都分成 4 个线程，对于某些查询，它们根本没有被阻塞，而是在等待“MISCELLANEOUS”，但对于某些查询，至少部分线程被其他查询阻塞。
例如，现在有 294 个线程正在显示。
查询 202 被分成 4 个线程，其中一个线程被 123 阻塞，但其他线程没有被阻塞。三个线程正在等待“MISCELLANEOUS”，阻塞线程正在等待“PAGELATCH_UP”
至于查询 123，它没有被阻塞，它有 4 个线程正在等待“MISCELLANEOUS”
或者例如，查询 219 在一个线程上被查询 140 阻塞，在其他三个线程上被 69 阻塞。
69 被 193 阻止，193 正在运行，再次等待“杂项”。140 不再在列表中，因此它要么超时要么已完成。
我的并行成本阈值为 70。
锁定 0
最大并行度 3
查询等待 -1
未在数据库上启用快照隔离级别。查询未使用快照隔离级别。
我还检查了表的统计信息，甚至 sys.change_tracking 表。对于查询的表，表上的索引没有碎片化（小于 10%）。
我运行了一个或两个查询，一般查询的结果是 4 行，由于 DISTINCT 子句而变成只有一行。所以它不像返回数千行。
当我在 SSMS 中运行查询时，它速度很快并且不会阻塞，即使我目前在同一查询的服务器上看到数百个被阻塞的查询。所以我想这可能与参数嗅探有关？
这是我在 SSMS 中执行时的 I/O 统计信息。
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 92 ms, elapsed time = 92 ms.
Table 'Users'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
(1 row affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscommittab'. Scan count 3, logical reads 555, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'change_tracking_62623266'. Scan count 1, logical reads 3364, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Table1'. Scan count 3, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Table2'. Scan count 0, logical reads 34281, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'change_tracking_46623209'. Scan count 1, logical reads 1152, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'change_tracking_78623323'. Scan count 1, logical reads 1077, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 296 ms, elapsed time = 435 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Completion time: 2020-01-22T14:18:25.9480651-05:00
这是我的查询计划 https://www.brentozar.com/pastetheplan/?id=By7k-7UWI
但同样，这是不阻止的版本。我启用了查询存储，所以我可以尝试获取阻止的版本，我只是不是 100% 如何做到这一点。
已编辑：查询商店信息
我的查询是查询存储的“回归查询”中的第一个。
根据查询商店，这里是“坏计划” https://www.brentozar.com/pastetheplan/?id=ryqKGQUbL
这是“好计划” https://www.brentozar.com/pastetheplan/?id=rknnGQ8WL
我应该“强迫”这个好计划吗？
编辑我的解决方案
好的，所以我使用了 Brent Ozar 的 sp_blitzcache ( https://www.brentozar.com/blitz/ )，“expert_mode”为 1，以便能够检索“坏计划”的句柄并能够从缓存（不清除任何其他内容）。
DBCC FREEPROCCACHE (0x06000800155A5106F08F632F1C00000001000000000000000000000000000000000000000000000000000000);
我的服务器再次恢复正常状态，所有数百个被阻止的查询都消失了。我猜那是参数嗅探？希望不要再发生了。想找个办法让它不再发生。
我正在使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 （构建 9600：）
昨天，我在同一数据库的“suspect_pages”中有两个条目。事件类型 1 和类型 2 之一
1 = 823 错误导致可疑页面（例如磁盘错误）或 824 错误而不是错误校验和或损坏页面（例如错误页面 ID）。
2 = 校验和错误。
database_id file_id page_id eventtype error_count last_update_date
8 1 1482057 1 1 2019-11-14 14:40
8 1 1482057 2 1 2019-11-14 14:40
我找到了相关的对象，它们都指向数据库上的同一个表。
DBCC TRACEON (3604);
DBCC PAGE (8, 1, 14823057, 0);
DBCC TRACEOFF (3604);
我在损坏之前有一个有效的备份并且无法承受停机时间，所以我对损坏的数据库进行了备份，并以新名称恢复了我的备份。我删除了损坏的表，然后从有效备份中重新创建了它。
今天，我恢复了昨天在测试服务器上进行的损坏的数据库备份，当我运行完整的 checkdb 时，它没有检测到损坏。
DBCC CheckDB() WITH No_INFOMSGS, ALL_ERRORMSGS
我从损坏的数据库中获取的备份（根据怀疑页面）怎么可能没有任何问题？可疑页面中的那些条目会是误报吗？
数据库兼容级别为 130 (SQL 2016) 我们的 SQL Server 在 Windows Server 2012 上运行。
我正在使用 Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) Jun 15 2019 23:15:58 版权所有 (c) Microsoft Corporation Standard Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 （构建 9600
：）我有多个数据库，在高插入/更新表上启用了 CHANGE_TRACKING。我的保留期是 2 天，启用了自动清理。数据库兼容性设置为 130 (SQL 2016)
跟踪的一些表很大，每天可能有数千个插入/更新。这是 change_tracking 表的内容。
这是我们为获取更改而执行的查询示例。
SELECT Columns
FROM CHANGETABLE(CHANGES MyTable, @TrackingKey) AS CT
INNER JOIN MyTable b ON b.Key=CT.Key
WHERE b.Status = 1
我不时看到，获取某些表的最新更改的查询需要很长时间才能完成，并且会产生大量 CPU。为了解决这个问题，我设置了每天晚上运行的更改跟踪表的每日更新统计信息。它有很大帮助，但有时，在用户活跃的日子里，即使在白天，我也必须运行此更新统计信息。当我在这些表上运行更新统计信息时，情况恢复正常，获取最新更改的查询在一段时间内运行良好。
我们对应用程序的某些重要部分使用更改跟踪，因此它必须工作。
是否有任何选项，我可以启用跟踪标志来帮助更改跟踪统计信息？任何有对高活动数据库进行更改跟踪的经验的人都可以给我一些建议吗？
所以我最终决定做一个工作来检查自上次统计更新以来更改跟踪表是否更改了超过 20k 行，然后该作业将更新更改跟踪表上的统计信息。
如果它可以帮助其他人，我会将查询放在这里。此查询为您提供自上次更新统计信息以来表更改超过 20k 次的更改跟踪表的所有统计信息。它为您提供了带有要更新的 object_name 的“更新统计信息”。您只需要在数据库上运行查询结果。我会根据我的工作量对其进行微调，看看 20k 是否是最佳数字。
SELECT
-- st.object_id AS [Table ID]
--, OBJECT_NAME(st.object_id) AS [Table Name]
--, st.name AS [Index Name]
--, STATS_DATE(st.object_id, st.stats_id) AS [LastUpdated]
--, modification_counter AS [Rows Modified]
'UPDATE STATISTICS sys.[' + OBJECT_NAME(st.object_id) + ']' as QueryToRun
FROM sys.stats st
CROSS APPLY sys.dm_db_stats_properties(st.object_id, st.stats_id) AS sp
WHERE OBJECT_NAME(st.object_id) like 'change_t%'
AND OBJECT_NAME(st.object_id) in (SELECT 'change_tracking_' + convert(nvarchar(50),st.object_id) FROM sys.change_tracking_tables ctt inner join sys.tables st ON st.object_id = ctt.object_id inner join sys.schemas ss ON ss.schema_id = st.schema_id)
AND modification_counter > 20000
我们正在使用 SQL Server 2016 标准版 (SP2-CU2)。我们有几台服务器，每台服务器托管几十到数百个数据库。我们从未在我们的数据库上启用查询存储。
我知道打开查询存储进行调优有很多好处。我想知道，是否存在不应该打开查询存储的情况？或者我应该在所有数据库上打开它吗？
已编辑
以防万一它可以帮助其他人。我最终所做的是启用查询存储一些数据库的时间，每天，并进行监控。到目前为止，我已经在我的几乎所有数据库上启用了查询存储，而没有任何性能影响。事实证明，它在调查问题时很有用。
我的其中一台 SQL Server 2016 Standard 服务器出现问题。我有 8 台生产服务器，这台是唯一一台随机崩溃而日志中没有任何痕迹的服务器。
我启用了 system_health。我注意到我在系统健康女巫中有一行是“sql_exit_invoked”。
我正在尝试查找有关该行的更多信息。这是什么意思？我在互联网上找到的唯一信息是它发生在调用 SQLExit() 时，并且它仅从 SQL 2012 开始记录。（链接在 msdn 网站上可用）
所以我的问题是：我应该担心在我的日志中看到这个吗？我只在我有问题的服务器上发现了这一点，而在其他 7 台服务器中没有发现。（均为SQL Server 2016标准版）
谁能给我更多关于这方面的信息？
我有一个 SQL Server 2016 SP1 生产服务器。它已经运行了 330 天而没有重新启动。一切都运行良好。直到上周的一天，突然之间，服务器上的每个查询都生成了一个编译。
通常当我检查 Perfmon 时，我看到很多 Batch Requests/Sec 但今天，我看到的 Requests/Sec 和 Compilations/Sec 一样多
当我试图查看什么正在使用我的缓存时，我一无所获！我从来没有见过这样的事情。它持续了一整天，CPU 一直处于 100%，因为它一直在编译。
最后，IT 决定重启机器。重启后一切都得到修复。但我想知道，你见过这样的事情吗？缓存计划会被破坏吗？（比如，如果我运行了 DBCC FREEPROCCACHE，它可能会在不重新启动的情况下自行修复？）
这是否意味着我应该至少每六个月左右重新启动一次服务器？
这是同一台服务器的常规基线。
我有SQL Server 2016。我有两张结构相同的表，一张包含历史数据，另一张包含当前数据。
我有一个程序使用的视图，它返回两个表的内容。
CREATE TABLE A (int Id IDENTITY(1,1) NOT NULL, othercolumns, primary key, ect.)
CREATE TABLE B (int Id NOT NULL, othercolumns, primary key, ect.)
CREATE VIEW MyView AS SELECT * FROM A UNION ALL SELECT * FROM B
CREATE TRIGGER TR_INSTEADOFINSERT_ON_MyView on MyView
INSTEAD OF INSERT
AS
BEGIN
INSERT INTO A (columns)
SELECT data
FROM inserted
END
我想知道每次在视图中完成插入时是否会重新创建视图。因为如果我检查 sys.dm_exec_sessions 和 sys.db_exec_requests，我总是会在查询文本中看到“CREATE TRIGGER TR_INSTEADOFINSERT”被执行。
现在我知道这需要很长时间，因为它是一张大桌子，而且我在服务器上有很多活动。但我只是想知道为什么我一直在正在执行的查询的 sql_text 中看到“CREATE TRIGGER”？是否重新创建？最有效的方法是什么？我应该修改程序以在插入时直接引用表格吗？
我使用的是 SQL Server 2016 SP1 标准版。
dm_db_index_physical_stats 视图在大型数据库上非常慢。即使我指定了“有限”选项。
我使用视图来获取索引碎片，以确定在维护中是否应该执行 REBUILD 或 REORG。但随着数据库的增长，对 DMV dm_db_index_physical_stats 的调用需要越来越多的时间。在某些可能高达 1TB 的数据库上，查询 DMV 可能需要一个小时。（我没有停机时间，总是有连接到数据库的客户端在工作。）
所以我想知道是否有一种方法可以在不查询 DMV 的情况下了解索引碎片。
我运行 SQL Server 2012。
我有一项每晚运行的维护工作。在维护结束时，我做了一些清理并调用它：
Begin try
Exec msdb.dbo.sysmail_delete_log_sp @logged_before = '20160613';
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp @sent_before = '20160613';
End try
Begin catch
-- Do some log error
End catch
我将事务放在 Try/Catch 中，但它似乎不起作用。我不断收到此错误：
“错误 1205，严重性 13，级别 18：事务（进程 ID 112）在锁定资源上与另一个进程发生死锁，并已被选为死锁牺牲品。重新运行事务。”
如果我手动运行事务，它运行得很快而且我不会收到任何错误。
任何想法为什么我不断收到此错误或如何捕获它以免我的工作失败？
我们正在尝试在许多数据库之间比较整个表的值。用户可以输入表名和列名，以及他想要比较的数据库名。
他们可以输入任意数量的数据库、表格和列。我们想比较每行的行数，只针对指定的列。
ex:
DatabaseA, DatabaseB, DatabaseC
Table1, Col1|Col2|Col3|Col4
Table2, Col1|Col4|Col5|Col6|Col20
...
例如，如果我有：
DatabaseA
Table1, Col1|Col2|Col3|Col4 = 'Apple', 1, 10, 'ABC'
DatabaseB
Table1, Col1|Col2|Col3|Col4 = 'Banana', 1, 10, 'ABC'
有区别。
起初，如果每个表（不包括用户未指定的列），我正在考虑在每行上使用 CHECKSUM 并比较 CHECKSUM，但我读过它并不总是唯一的。
现在我正在考虑使用 HASHBYTES 代替。通过这样做：
SELECT HASHBYTES('sha2_512', CONVERT(NVARCHAR(MAX), ISNULL(col1,'')) +
HASHBYTES('sha2_512', CONVERT(NVARCHAR(MAX), ISNULL(col2,'')) +
HASHBYTES('sha2_512', CONVERT(NVARCHAR(MAX), ISNULL(col3,'')) +
HASHBYTES('sha2_512', CONVERT(NVARCHAR(MAX), ISNULL(col4,'')) +
FROM Table1
或者通过这样做：
With Vals AS
(
SELECT CONVERT(NVARCHAR(MAX), ISNULL(col1, '')) +
CONVERT(NVARCHAR(MAX), ISNULL(col2, '')) +
CONVERT(NVARCHAR(MAX), ISNULL(col3, '')) +
CONVERT(NVARCHAR(MAX), ISNULL(col4, '')) AS Val
FROM Table1
)
SELECT HASHBYTES ('sha2_512', Val) FROM Vals
你怎么看？你会怎么做？最好的方法是什么？
谢谢
我的计算机上安装了带有 SP1 的 SQL 2012。我做了一个数据库的备份test.bak。
我有一个名称test2相同的数据库，但数据发生了变化。
我想test.bak通过test2数据库恢复。
我总是收到错误：
错误 3154：备份集保存现有数据库以外的数据库的备份。
我试过了：
我右击test2 -> Restore database -> From device
我选择test.bak并检查了With Replace但我得到了错误。
然后我尝试右键单击test2 -> Restore file and filegroups
我选择test.bak并检查了With Replace但我得到了错误。
我可以删除我的旧数据库，然后使用正确的名称恢复我的备份，但是当我使用 SQL 2008 时，我在现有数据库上恢复没有问题。
看来自从我使用SQL2012以来，我经常遇到这个错误！