Danielle Paquette-Harvey's questions

Estou trabalhando com SQL Server 2016 e SQL Server 2019 Standard Edition. Nós temos esse trabalho que está lá há um tempo. Costumava ser pequeno, mas agora executa dezenas de SELECT/DELETEinstruções. (Não há GOseparador entre as declarações.)

• Eu queria saber como o SQL Server aloca RAM para etapas de trabalho?
• O SQL tentará alocar a RAM para toda a etapa de uma só vez?
• Ou ele alocará a RAM para cada consulta enquanto executa a etapa?
• Considerando o uso de RAM, seria melhor fazer etapas diferentes para o trabalho?

Provavelmente vou acabar separando o trabalho de qualquer maneira, mesmo que apenas para fins de monitoramento. Mas como estamos usando a edição SQL Standard, monitoro de perto o uso da RAM e não consegui encontrar informações sobre a alocação dentro dos trabalhos do SQL Agent.

Eu tenho um servidor de produção SQL Server 2016 Standard com mais 59 bancos de dados de clientes.

Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) - 13.0.5888.11 (X64) 19 de março de 2021 19:41:38 Direitos autorais (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2019 Standard 10.0 (Build 17763: )

Este servidor é muito usado e o Repositório de Consultas está habilitado em todos os bancos de dados. Meu maior banco de dados no servidor tem cerca de 800 GB de tamanho. Ele também usa cerca de 15% do subsistema de E/S sozinho.

Estou usando o proc sp_blitzcache do Brent Ozar e venho pesquisando as consultas mais executadas no servidor desde que estou vendo um aumento nas consultas executadas/segundo no Perfmon.

Agora, minhas consultas mais executadas não são consultas de usuários. As consultas mais executadas são consultas internas de limpeza do Repositório de Consultas, no maior banco de dados.

Não sei exatamente o que fazer sobre isso (além de tentar habilitar/desabilitar o Query Store no banco de dados). Se eu fizer isso, perderei todos os dados coletados.

O Change Tracking está configurado para manter 2 dias de dados com limpeza automática.

Você acha que essas consultas podem estar causando problemas no meu servidor?

Alguém experimentou algo parecido?

Estou usando esta versão do 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: ) 

Isso pode parecer contra-intuitivo, mas quero que alguns dos meus trabalhos não enviem um e-mail quando falharem.

Eu tenho um servidor muito ocupado e alguns dos trabalhos falham quando entram em um impasse com outros processos. Estou bem com isso, desde que na maioria das vezes o trabalho seja bem-sucedido.

Eu estava recebendo muitos e-mails de falha de trabalho, então, em vez disso, fiz um relatório que me dá os trabalhos que falharam ontem e o número de ocorrências que falharam.

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

Meu problema é que, embora eu tenha desmarcado a Notificação no SSMS, ainda estou recebendo e-mails quando o trabalho trava.

Alguma ideia do que preciso desativar? Preciso desabilitar o operador à prova de falhas? Eu gostaria de evitar isso, se possível.

Estou usando o SQL Server 2016

Microsoft SQL Server 2016 (SP2-CU14) (KB4564903) - 13.0.5830.85 (X64) 31 de julho de 2020 18:47:07 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Build 9600) : )

Eu tenho essa tabela que tem dois campos Datetime, um StartDate e um EndDate. Aqui está uma versão simplificada.

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)

A tabela de amostra não é muito grande, mas consigo os mesmos planos de consulta que na produção. Esta tabela tem cerca de 50 milhões de linhas. Temos uma consulta para um relatório que está demorando muito para ser executado.

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)

A consulta por si só não demora "isso" para ser executada, mas o servidor está muito ocupado e de vez em quando recebo deadlocks com outras consultas do sistema.

Eu gostaria de poder remover o predicado e ter apenas um predicado de busca e reduzir o número de leituras porque agora ele lê mais de 3 milhões de linhas para recuperar 155 linhas.

Aqui está o plano de consulta (do banco de dados de produção)

Eu poderia ser capaz de alterar as coisas no código ou no banco de dados para fazer isso funcionar. Qualquer ajuda seria apreciada. Já tentei ajustar o índice ou brincar com a consulta mas não estou chegando a lugar nenhum.

************************ ATUALIZAR ************************* *****************

Eu tentei a consulta proposta por JD

Isso me dá um plano de execução diferente, mas as estimativas ainda estão longe. Aqui está o plano de consulta.

Talvez uma dica de consulta ajude? O nível de compatibilidade do banco de dados é 130.

Eu tentei usar a dica de consulta

OPTION (FAST 100)

As estimativas de cardinalidade são melhores, pois digo basicamente ao SQL para esperar 100 linhas, mas as leituras não mudam. A atualização das estatísticas não muda nada (elas são atualizadas todas as noites).

Talvez não tenha como ter um resultado melhor com uma mesa tão grande?

****************************** EDIT 2 minha solução **************** *****************

Apenas no caso de poder ajudar alguém com o mesmo problema. Limitar o intervalo de datas conforme proposto na segunda solução desta questão resolveu meus problemas. Também vou reescrever a consulta como JD propôs, então marcarei sua resposta como a resposta.

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' ;

Eu tive um servidor SQL Server 2019 funcionando muito bem nos últimos meses, mas começou a parar sozinho desde a última sexta-feira. Esta manhã, instalei a atualização cumulativa mais recente nele.

Aqui está a minha versão

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) 2 de novembro de 2020 18:35:09 Copyright (C) 2019 Microsoft Corporation Developer Edition (64 bits) no Windows Server 2019 Standard 10.0 ( Compilação 17763: ) (Hipervisor)

Também tive o problema com a edição padrão do SQL Server 2019 (RTM-CU8-GDR).

Cada vez, um minidump foi criado. Depois de analisar os dumps, posso ver uma exceção de base do kernel.

Este servidor roda apenas SQL Server, não tenho mais nada rodando na máquina.

No arquivo de log do SQL vejo o dump sendo feito logo após essa mensagem.

No Visualizador de Eventos do Windows, só tenho um erro dizendo que o SQL está parando.

E pouco antes desse erro, eu tenho o erro "Relatório de erros do Windows" sobre SQLException64.

Reiniciar o SQL Server não muda nada. Mas, se eu abrir o SQL Management Console e iniciar o SQL Service, ele iniciará bem.

Eu realmente não sei onde verificar, como diagnosticá-lo ainda mais.

Aqui está o arquivo de mini dump.

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)

Eu adicionei meus dumps aqui e a saída do texto WinDbg lmv aqui: https://www.dropbox.com/sh/fkcsdrb7iu5b1oi/AACa9VMgZ4CWzyhnLNL7W0Saa?dl=0

Atualização: A desativação do broker corrigiu o problema. No entanto, não posso mantê-lo assim, pois usamos o broker em produção. Acho que não terei escolha a não ser entrar em contato com a Microsoft sobre isso.

Estou usando o Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64) 15 de fevereiro de 2020 01:47:30 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Construção 9600: )

Eu tenho algumas tabelas muito grandes (as tabelas sozinhas podem ter mais de 700 gb) em um banco de dados de 2,5 terabytes.

Eu tenho usado alguns scripts para manutenção de índice. No momento estou fazendo:

• Reorganizar se a fragmentação for > 10%
• Reconstrua se a fragmentação for > 50%.

Funciona bem na maioria das vezes, mas para minhas tabelas de 700 GB ou maiores, acho que 10% será uma porcentagem difícil de atingir. Eu queria saber se devo diminuir essa porcentagem para essas grandes mesas ou se é bom deixá-la nesse limite.

Devo acrescentar que meus servidores possuem drivers SSD, mas apenas 128 GB de RAM porque é a edição Standard. Portanto, não há como as tabelas caberem na RAM, no caso de consultas grandes (como relatórios), é necessário escanear/buscar os índices.

Não quero atingir a limitação do sistema de arquivos de erro 665 devido à fragmentação. https://learn.microsoft.com/en-ie/troubleshoot/sql/admin/1450-and-665-errors-running-dbcc (estou começando a adicionar grupos de arquivos ao banco de dados para evitar esse erro, pois estou estou tendo de vez em quando nas grandes tabelas que fazem parte do grupo de arquivos primário.)

Então, devo fazer uma porcentagem personalizada para manutenção de índice em tabelas muito grandes? Ou deve ser bom?

Estou trabalhando com o Microsoft SQL Server 2016 (SP2-CU11) (KB4527378) - 13.0.5598.27 (X64) 27 de novembro de 2019 18:09:22 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Padrão 6.3 (Build 9600: )

Este servidor está em unidades SSD e tem uma memória máxima de 128 GB. CostTheshold para Paralelismo é 70, MaxDegree de Paralelismo é 3.

Eu tenho uma tabela "Trips" que é referenciada por 23 chaves estrangeiras com a opção ON DELETE CASCADE.

Esta tabela por si só não é tão grande (5,3 milhões de linhas, 1,3 gb de dados). Mas das 23 tabelas referenciadas, duas das tabelas são bem grandes (mais de 1 bilhão de linhas, 54 e 69 gb cada).

O problema é que quando tentamos excluir uma pequena quantidade de linhas na tabela "Trips" (digamos 4 linhas), o SQL estima que tantas linhas serão excluídas, ele pede 10 GB de RAM, estima que milhões de linhas serão retornado e bloqueia a tabela. Tudo para e outras consultas são bloqueadas e o aplicativo expira.

Aqui estão as tabelas principais e a contagem de linhas para 1 instrução de exclusão:

• Viagens (4 linhas)
• Segmentos (27 linhas, relacionadas a Viagens por SegmentId)
• Perfis (linhas de 2012, relacionadas a Segmentos por SegmentId)
• ProfileRanges (2337 linhas, relacionadas a perfis por ProfileId)
• Eventos (7.750 linhas, relacionadas a segmentos por SegmentId)
• EventConditions (9230 linhas, relacionadas a eventos por EventId)

As tabelas EventConditions e ProfileRanges têm mais de 1 bilhão de linhas cada.

Aqui está o cache do plano: https://www.brentozar.com/pastetheplan/?id=HJNg5I0BU

Quando olho no explorador de planos SentryOne, posso ver que o SQL está lendo a tabela inteira, mesmo que o "spool de tabela" filtre e mantenha apenas para 2012 linhas ProfileRanges e quase o mesmo para EventConditions.

Quando olho para a concessão de memória da consulta com o procedimento sp_blitzCache de Brent Ozar, posso ver que a consulta pede cerca de 10 GB de RAM.

Depois disso, a consulta está esperando em SOS_SCHEDULER_YIEL (então esperando a vez de usar a CPU após os 4ms) ou MEMORY_ALLOCATION_EXT. O programa expira e falha.

O que posso fazer para que isso funcione?

Uma das coisas que eu estava pensando era remover as chaves estrangeiras nas duas maiores tabelas e excluir suas linhas em um gatilho em vez de. Mas eu não sou um grande fã de impor a consistência do banco de dados com gatilhos em vez de chaves estrangeiras.

Qualquer conselho ou ajuda será apreciado

A chave primária de ProfileRanges é

• PerfilId int
• ProfileRangeDefId1 int
• ProfileRangeDefId2 int

A chave primária de EventConditions é

• EventId bigint
• EventConditionDefId int

Estou usando o Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) 15 de junho de 2019 23:15:58 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Construção 9600:)

O banco de dados tem cerca de 870 GB de tamanho. É SQL Standard e tenho 128 GB de RAM no servidor. O banco de dados está em unidades SSD. O arquivo de dados está em uma unidade diferente do arquivo de log e o Tempdb também possui sua própria unidade SSD. O servidor recebe cerca de 1200 consultas/segundo em média, podendo chegar a 2000 consultas/segundo. A recompilação permanece baixa, apenas 1 a 8 por segundo. A expectativa de vida da página é boa, com média de 61 minutos.

O servidor possui 6 núcleos físicos + hyper threads.

Estamos usando muito o rastreamento de alterações do SQL Server em um sistema em que milhares de dispositivos se conectam e tentam sincronizar as alterações com a chave de rastreamento.

Geralmente roda bem, mas depois, de vez em quando, um dia ou outro, os travamentos do servidor disparam, passando de 0ms para uma média de 60677ms.

Quando verifico quais consultas estão em execução, só vejo as consultas de sincronização, todas bloqueadas, com "PAGELATCH_UP", todas tentando acessar as tabelas de controle de alterações, mais de 300 consultas bloqueadas.

Eu tenho algumas perguntas:

• O SQL Server bloqueia a tabela inteira enquanto procura alterações no controle de alterações?
• Teria melhores resultados com o SQL Entreprise ou não muda nada?
• Alguma ideia de por que o rastreamento de alterações funciona bem na maioria das vezes, mas trava sem motivo aparente de semana para semana?

Esses são o tamanho da minha tabela de rastreamento de alterações. As tabelas que minha consulta bloqueia são as três primeiras, apenas alguns mb de dados.

Eles estão todos esperando no mesmo waitresource.

Waitresource 2:4:88968 está no tempdb. Mas o tempdb é responsável apenas por cerca de 9% das gravações do servidor e 6% das leituras.

Mas minha consulta não usa o tempdb, então acho que é assim por causa da maneira interna como o rastreamento de alterações funciona? Aqui está minha consulta

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 

Meu tempdb tem 10 arquivos e eles são do mesmo tamanho.

O que geralmente acabo fazendo para que o cliente volte ao normal é colocá-lo em tempo de inatividade, depois colocá-lo de volta aos poucos para que todos os dispositivos móveis consigam sincronizar pouco a pouco. Mas nosso sistema é de missão crítica e esta não é uma solução de longo prazo.

Outra solução que tenho pensado é mudar a forma como o sistema funciona com as consultas de controle de alterações. Faça com que o dispositivo móvel sincronize com uma tabela "feita em casa" e preencha essa tabela com uma única alteração de leitura de serviço do rastreamento de alterações. Dessa forma, limitarei as consultas simultâneas às tabelas de controle de alterações, mas temo que apenas mova o problema para a tabela feita em casa.

Algum pensamento sobre isso? Qualquer ajuda será apreciada.

EDITADO: Bloqueador de cabeça

Tentei determinar quem é o bloqueador de cabeça e o que está esperando, mas é uma tarefa difícil. Parece que tenho muitos "bloqueadores de cabeça".

Todas as consultas estão executando o mesmo SELECT, quase todas divididas em 4 threads, para algumas consultas elas não estão bloqueadas, mas aguardando "MISCELLANEOUS", mas para algumas consultas, pelo menos parte das threads são bloqueadas por outras consultas.

Por exemplo, agora, 294 tópicos estão sendo exibidos.

A consulta 202 é dividida em 4 threads e uma de suas threads está bloqueada por 123, mas as outras threads não estão bloqueadas. Os três encadeamentos estão aguardando em "MISCELLANEOUS" e o encadeamento bloqueado está aguardando em "PAGELATCH_UP"

Quanto à consulta 123, ela não está bloqueada, são 4 threads aguardando "DIVERSOS"

Ou, por exemplo, a consulta 219 é bloqueada pela consulta 140 em um encadeamento e bloqueada por 69 nos outros três encadeamentos.

69 está bloqueado por 193 e 193 está em execução, aguardando "MISCELLANEOUS" novamente. 140 não está mais na lista, por isso expirou ou foi concluído.

Meu limite de custo para paralelismo é 70.
Bloqueios 0
Grau máximo de paralelismo 3
Espera de consulta -1

O nível de isolamento do instantâneo não está habilitado no banco de dados. As consultas não estão usando o nível de isolamento de instantâneo.

Também verifiquei as estatísticas nas tabelas e até nas tabelas sys.change_tracking. Os índices nas tabelas não são fragmentados (menos de 10%) para as tabelas consultadas.

Executei uma ou duas consultas e geralmente o resultado da consulta é de 4 linhas, que se tornam apenas uma linha por causa da cláusula DISTINCT. Portanto, não é como se estivesse retornando milhares de linhas.

Quando executo a consulta no SSMS, ela é rápida e não bloqueia, mesmo que atualmente veja centenas de consultas bloqueadas no servidor na mesma consulta. Então eu acho que pode estar relacionado ao sniffing de parâmetros, talvez?

Aqui estão as estatísticas de E/S quando executo no SSMS.

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

Aqui está meu plano de consulta https://www.brentozar.com/pastetheplan/?id=By7k-7UWI

Mas, novamente, essa é a versão que não bloqueia. Eu tenho o repositório de consultas habilitado para que eu pudesse tentar obter a versão que bloqueia, só não estou 100% como fazê-lo.

EDITADO: QUERY STORE INFO

Minha consulta é a primeira nas "consultas regredidas" do Query Store.

De acordo com a loja Query, aqui está o "plano ruim" https://www.brentozar.com/pastetheplan/?id=ryqKGQUbL

E aqui está o "bom plano" https://www.brentozar.com/pastetheplan/?id=rknnGQ8WL

Devo apenas "forçar" o bom plano?

EDITADO Minha solução

Ok, então eu usei o sp_blitzcache de Brent Ozar ( https://www.brentozar.com/blitz/ ) com "expert_mode" em 1 para poder recuperar o identificador do "plano ruim" e poder limpá-lo de cache (sem limpar mais nada).

DBCC FREEPROCCACHE (0x06000800155A5106F08F632F1C00000001000000000000000000000000000000000000000000000000000000);

Meu servidor voltou ao estado normal novamente e todas as centenas de consultas bloqueadas desapareceram. Eu acho que é sniffing de parâmetros então? Esperando que não aconteça novamente. Gostaria de encontrar uma maneira para que isso não aconteça novamente.

Estou usando o Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) 15 de junho de 2019 23:15:58 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Construção 9600:)

Ontem, recebi duas entradas em "suspect_pages" para o mesmo banco de dados. Um do tipo de evento 1 e um do tipo 2

1 = Um erro 823 que causa uma página suspeita (como um erro de disco) ou um erro 824 diferente de uma soma de verificação incorreta ou uma página rasgada (como uma ID de página incorreta).

2 = Soma de verificação ruim.

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

Encontrei o objeto relacionado e ambos apontam para a mesma tabela no banco de dados.

DBCC TRACEON (3604); DBCC PAGE (8, 1, 14823057, 0); DBCC TRACEOFF (3604);

Eu tinha um backup válido de antes da corrupção e não podia pagar um tempo de inatividade, então fiz um backup do banco de dados corrompido, restaurei meu backup em um novo nome. Soltei a tabela corrompida e a recriei a partir do backup válido.

Hoje, restaurei o backup de banco de dados corrompido que fiz ontem em um servidor de teste e quando executo um checkdb completo, ele não detecta corrupção.

DBCC CheckDB() COM No_INFOMSGS, ALL_ERRORMSGS

Como é possível que o backup que fiz de um banco de dados corrompido (de acordo com as páginas suspeitas) não tenha problemas? Essas entradas em páginas suspeitas podem ser um falso positivo?

O nível de compatibilidade do banco de dados é 130 (SQL 2016) Nosso SQL Server está sendo executado no Windows Server 2012.

Estou usando o Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) 15 de junho de 2019 23:15:58 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Build 9600: )

Tenho vários bancos de dados com CHANGE_TRACKING habilitado em tabelas de alta inserção/atualização. Meu período de retenção é de 2 DIAS, com a limpeza automática habilitada. A compatibilidade do banco de dados está definida como 130 (SQL 2016)

Algumas das tabelas rastreadas são enormes e podem ter milhares de inserções/atualizações todos os dias. Este é o conteúdo das tabelas change_tracking.

Aqui está um exemplo de consulta que fazemos para obter as alterações.

SELECT Columns
FROM CHANGETABLE(CHANGES MyTable, @TrackingKey) AS CT 
INNER JOIN MyTable b ON b.Key=CT.Key
WHERE b.Status = 1

Tenho visto de tempos em tempos que as consultas para obter as últimas alterações em algumas das tabelas levam muito tempo para serem concluídas e geram muita CPU. Para ajudar com isso, configurei uma estatística de atualização diária nas tabelas de controle de alterações que são executadas todas as noites. E isso ajuda muito, mas às vezes, em dias de alta atividade do usuário, tenho que executar essa atualização de estatísticas mesmo durante o dia. Quando executo as estatísticas de atualização nessa tabela, a situação volta ao normal e as consultas para obter as alterações mais recentes funcionam bem por algum tempo.

Usamos o controle de alterações para algumas partes vitais de nossos aplicativos, por isso tem que funcionar.

Existe alguma opção, sinalizador de rastreamento que eu possa ativar para ajudar nas estatísticas de rastreamento de alterações? Alguém tem experiência com rastreamento de alterações em bancos de dados de alta atividade pode me dar alguns conselhos?

Então, finalmente decidi fazer um trabalho para verificar se a tabela de controle de alterações mudou mais de 20 mil linhas desde a última atualização de estatística, então o trabalho atualizará as estatísticas na tabela de controle de alterações.

Vou colocar a consulta aqui se puder ajudar alguém. Essa consulta fornece todas as estatísticas para tabelas de controle de alterações em que a tabela foi alterada mais de 20 mil vezes desde a última atualização das estatísticas. Ele fornece uma "Atualização de Estatísticas" com o object_name para atualizar. Você só precisa executar os resultados da consulta em seu banco de dados. Vou ajustá-lo para minha carga de trabalho e ver se 20k é o melhor número.

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 

Estamos usando o SQL Server 2016 Standard Edition (SP2-CU2). Temos alguns servidores hospedando cada um entre algumas dezenas a centenas de bancos de dados. Nunca habilitamos o Query Store em nossos bancos de dados.

Eu sei que há muitas vantagens em ativar o Repositório de Consultas para ajuste. Eu queria saber, existem casos em que o armazenamento de consultas não deve ser ativado? Ou devo ativá-lo em todos os bancos de dados?

EDITADO

Apenas no caso de poder ajudar outras pessoas. O que acabei fazendo foi habilitar a consulta armazenar alguns bancos de dados ao mesmo tempo, todos os dias, e monitorar. Até agora, eu tinha o repositório de consultas habilitado em quase todos os meus bancos de dados sem nenhum impacto no desempenho. Ele provou ser útil ao investigar problemas.

Estou tendo problemas com um dos meus servidores SQL Server 2016 Standard. Tenho 8 servidores de produção e este é o único que trava aleatoriamente sem ter nenhum rastro no log.

Eu tenho system_health habilitado nele. Percebi que tenho uma linha na saúde do sistema que é "sql_exit_invoked".

Estou tentando encontrar mais informações sobre essa linha. O que isso significa? A única informação que encontrei na internet é que isso acontece quando SQLExit() é chamado e que está logado apenas desde o SQL 2012. (link disponível no site do msdn )

Então minha pergunta é: Devo me preocupar em ver isso no meu log? Acho isso apenas no meu servidor problemático e não em nenhum dos outros 7 servidores. (Todos eles são SQL Server 2016 Standard edition)

Alguém pode me dar mais informações sobre isso?

Eu tenho um servidor de produção do SQL Server 2016 SP1. Está em execução sem reinicialização há 330 dias. Tudo tem corrido bem. Até a semana passada, um dia, de repente, cada consulta no servidor estava gerando uma compilação.

Normalmente, quando eu verifico o Perfmon, vejo muitas solicitações de lote/seg, mas neste dia, vi tanto solicitações/seg quanto compilações/seg.

Quando tentei ver o que está usando meu cache, não tinha nada! Eu nunca vi nada assim. Ele continuou e durante todo o dia, a CPU estava em 100%, pois estava compilando o tempo todo.

Finalmente, a TI decidiu reiniciar a máquina. Tudo foi corrigido após uma reinicialização. Mas eu queria saber, você já viu algo assim? O plano de cache pode estar corrompido ou algo assim? (Como, talvez, se eu tivesse executado um DBCC FREEPROCCACHE, ele teria se consertado sem reiniciar?)

Isso significa que devo reiniciar meu servidor pelo menos uma vez a cada seis meses?

Aqui está uma linha de base regular para o mesmo servidor.

Tenho o SQL Server 2016. Tenho duas tabelas com a mesma estrutura, uma contém dados históricos e a outra contém dados atuais.
Eu tenho uma visão que os programas usam, que retorna o conteúdo das duas tabelas.

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 

Eu queria saber se a exibição é recriada toda vez que uma inserção é feita na exibição. Porque se eu verificar no sys.dm_exec_sessions e sys.db_exec_requests, sempre vejo o "CREATE TRIGGER TR_INSTEADOFINSERT" no texto da consulta a ser executado.

Agora sei que está demorando muito porque é uma mesa grande e tenho muita atividade no servidor. Mas eu só queria saber porque continuo vendo o "CREATE TRIGGER" no sql_text da query sendo executada? É recriado ou não? Qual é a maneira mais eficiente de fazer isso? Devo modificar os programas para referenciar a tabela diretamente ao inserir?

Estou usando a edição padrão do SQL Server 2016 SP1.

A visualização dm_db_index_physical_stats é muito lenta em bancos de dados grandes. Mesmo se eu especificar a opção 'LIMITED'.

Eu uso a view para obter a fragmentação do índice, para determinar se devo fazer um REBUILD ou um REORG na minha manutenção. Mas à medida que os bancos de dados crescem, a chamada para o DMV dm_db_index_physical_stats leva cada vez mais tempo. Em alguns bancos de dados, que podem ter até 1 TB, pode levar uma hora para consultar o DMV. (Não tenho tempo de inatividade, sempre há clientes conectados ao banco de dados trabalhando.)

Então eu queria saber se existe uma maneira de saber a fragmentação do índice sem consultar o DMV.

Eu executo o SQL Server 2012.
Tenho um trabalho de manutenção que é executado todas as noites. No final da manutenção, faço uma limpeza e chamo isso:
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

Coloquei a transação em um Try/Catch, mas parece que não está funcionando. Continuo recebendo este erro:
"Erro 1205, Gravidade 13, nível 18: a transação (ID do processo 112) estava em um impasse nos recursos de bloqueio com outro processo e foi escolhida como a vítima do impasse. Execute novamente a transação."

Se eu executar a transação manualmente, ela será executada rapidamente e não haverá erros.
Alguma ideia de por que continuo recebendo esse erro ou como posso detectá-lo para que não falhe no meu trabalho?

Estamos tentando comparar os valores de tabelas inteiras entre muitos bancos de dados. O usuário pode inserir na entrada os nomes das tabelas e das colunas e os nomes dos bancos de dados que deseja comparar.

Eles podem inserir quantos bancos de dados, tabelas e colunas desejarem. Queremos comparar linhas por linhas, apenas para as colunas especificadas.

ex:
DatabaseA, DatabaseB, DatabaseC
Table1, Col1|Col2|Col3|Col4
Table2, Col1|Col4|Col5|Col6|Col20
...

Então, por exemplo, se eu tiver:

DatabaseA
Table1, Col1|Col2|Col3|Col4 = 'Apple', 1, 10, 'ABC'

DatabaseB
Table1, Col1|Col2|Col3|Col4 = 'Banana', 1, 10, 'ABC'

Há uma diferença.

No começo, eu estava pensando em usar o CHECKSUM em cada linha se cada tabela (excluindo as colunas que não foram especificadas pelo usuário) e comparar o CHECKSUM, mas li que nem sempre é único.

Agora eu estava pensando em usar HASHBYTES. Ou fazendo isso:

    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

Ou fazendo isso:

   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

O que você acha? Como você faria? Qual seria a melhor forma?

Obrigado

Eu tenho o SQL 2012 com SP1 instalado no meu computador. Fiz um backup de um banco de dados test.bak.

Tenho um banco de dados com o nome test2que é o mesmo banco de dados, mas os dados mudaram.

Eu quero restaurar test.baksobre test2banco de dados.

Estou sempre recebendo o erro:

Erro 3154: O conjunto de backup contém um backup de um banco de dados diferente do banco de dados existente.

Eu tentei:

1. eu cliquei com o botão direitotest2 -> Restore database -> From device

   Eu escolhi test.bake verifiquei With Replace, mas recebo o erro.

2. Então eu tentei clicar com o botão direito do mouse emtest2 -> Restore file and filegroups

   Eu escolhi test.bake verifiquei With Replace, mas recebo o erro.

Posso excluir meu banco de dados antigo e restaurar meu backup com o nome correto, mas quando estava usando o SQL 2008, não tive problemas para restaurar um banco de dados existente.

Parece que desde que eu uso o SQL2012, recebo muito esse erro!