Sicilian-Najdorf's questions

Tenho uma consulta que atinge uma tabela de 1,4 bilhão de linhas.

Tudo funciona bem com essa consulta, em menos de um segundo.

Então, uma vez a cada 5 dias, mais ou menos, as estatísticas de atualização automática entram em ação e a consulta começa a ser executada por quase 60 segundos. Ela adota um plano diferente.

Verifiquei e quando as estatísticas de atualização automática são ativadas, a taxa de amostragem é inferior a 1% da tabela.

Agora, minha pergunta é: uma atualização automática de estatísticas pode fazer com que o otimizador escolha um plano pior do que o anterior?

Posso ver que as estimativas do plano ruim são muito diferentes das do plano bom.

Bom plano:

Plano Ruim:

As estimativas estão claramente erradas para o plano ruim e, ainda assim, a quantidade de linhas retornadas pela consulta é a mesma.

Neste ponto, estou tentando confirmar se uma atualização automática de estatísticas pode fazer isso?

O que estou tentando agora é fazer uma atualização de estatísticas com uma amostra de 10% e ver o que acontece.

Atualização: Concluí uma atualização de estatísticas com taxa de amostragem de 10% e as consultas estão indo bem novamente.

Tornei isso uma tarefa a ser executada regularmente.

Eu configurei a seguinte configuração de AG nas VMs do Azure 3 (SQL 2019)

Server1 e Server2 estão na mesma região e estão configurados com failover automático e modo de confirmação síncrona. Server3 está em outra região e configurado com failover manual e modo de confirmação assíncrona. Portanto, em operações normais: AG está ativo no Server1 O quorum do cluster está configurado como Server1 e Server2 tendo um voto com uma testemunha de compartilhamento de arquivo.

Portanto, se eu fosse fazer failover para DR (Server3), minha ideia seria a seguinte:

• Altere o Server3 para o modo de confirmação síncrona
• Failover AG para Servidor3
• Altere Server1 e Server2 para o modo de confirmação assíncrono com failover manual
• Remova os votos de quorum do cluster de Server1 e Server2
• Atribua a Server3 um voto de quorum de cluster.

Se eu fosse fazer failback para Server1, minha ideia seria a seguinte:

• Altere Server1 e Server2 para o modo de confirmação síncrona
• Failover AG para Servidor1
• Altere Server3 para o modo de confirmação assíncrono
• Remova os votos de quorum do cluster do Server3
• Atribuir votos de quorum de cluster para Server1 e Server2

Estou no caminho certo aqui? A ordem dos meus passos talvez seja um problema?

Qualquer conselho seria apreciado

Obrigado

Recentemente, lidei com um procedimento armazenado problemático. Às vezes, corre lindamente rápido, outras vezes, corre muito, muito tempo. Eu determinei que a detecção de parâmetros ruins era a causa.

Apenas para informação - Os parâmetros no proc são datetime e a consulta usa esses parâmetros para pesquisar intervalos de datas.

De qualquer forma, foi isso que tentei:

1. Recriou o proc e usou WITH RECOMPILE- Não ajudou
2. Recriou o proc e adicionou OPTION (RECOMPILE)- Não ajudou
3. Recriou o proc e adicionou OPTION (OPTIMIZE FOR UNKNOWN)- Executa rápido
4. Recriou o proc e usou variáveis ​​locais - Executa rápido

Para ajudar no meu entendimento... Está usando variáveis ​​locais e OPTIMIZE FOR UNKNOWNexatamente a mesma coisa da maneira que usa dados estatísticos de densidade média para produzir um plano?

Eu tentei algumas combinações de coisas também:

5. Recriou o proc e adicionou OPTIMIZE FOR UNKNOWN & OPTION (RECOMPILE) - Executa rápido
6. Recriado o proc com variáveis ​​locais & OPTION (RECOMPILE) - Executa lento

Eu li sobre os perigos potenciais do uso OPTIMIZE FOR UNKNOWNe, em muitos casos, o uso de variáveis ​​locais é apresentado como se fosse a mesma coisa. Isso é o que me leva a pensar que é a mesma coisa.

MAS - Como explico que a tentativa 6 corre devagar.

Quero dizer que sim, as estatísticas são atualizadas, mas com uma taxa de amostragem menor que zero% - as tabelas são ENORMES +- 1,6 bilhão de linhas.

Também pode ser digno de nota - eu usei o awesome sp_blitzcachee filtrei no proc específico - Há um aviso de tempo limite de compilação para ele - Minha intuição está me dizendo que é algo a ser observado aqui.

Alguém pode me ajudar a esclarecer algo em relação aos ouvintes AlwaysOn em 2 sub-redes. Windows Server 2019 SQL Server 2019 Isso está no Azure

Eu criei um AG de várias sub-redes. O ouvinte tem 2 endereços IP, um de cada região/sub-rede.

É normal que o ping do ouvinte sempre atinja o tempo limite, mesmo quando o ping é resolvido para o endereço IP que está online no momento? O ping responde ao fazer ping do próprio primário, mas em qualquer lugar fora deste servidor não responde O que estou querendo dizer é que o ping não é uma ferramenta confiável para confirmar a conectividade com um ouvinte AlwaysOn.

Em relação à conexão com o ouvinte. Eu li sobre as configurações de cluster RegisterAllprovidersIP e HostRecordTTL para solucionar problemas de desconexões intermitentes. Se o cliente suportar MULTISUBNETFAILOVER - É seguro dizer que essas configurações não importam? Eu acho que só mexeremos nessas configurações se o cliente não tiver a opção de MULTISUBNETFAILOVER

Algum conselho?

Obrigado

Alguém poderia me orientar para uma melhor compreensão das buscas de índice com vários predicados de desigualdade. Considere a seguinte tabela:

CREATE TABLE [dbo].[table_1](
[DBINVHDID] [int] IDENTITY(1,1) NOT NULL,
[TYPE] [nvarchar](1) NULL,
[INV_NO] [nvarchar](13) NULL,
[ACCOUNT] [nvarchar](10) NULL,
[NAME] [nvarchar](40) NULL,
[ADDR1] [nvarchar](25) NULL,
[ADDR2] [nvarchar](25) NULL,
[ADDR3] [nvarchar](25) NULL,
[CONTACT] [nvarchar](25) NULL,
[GST_NO] [nvarchar](15) NULL,
[CR_TERMS] [nvarchar](10) NULL,
[OREF] [nvarchar](20) NULL,
[YREF] [nvarchar](20) NULL,
[SALESREP] [nvarchar](20) NULL,
[DISCOUNT] [decimal](18, 2) NULL,
[TRANSPORT] [decimal](18, 2) NULL,
[INS] [decimal](18, 2) NULL,
[GST] [decimal](18, 2) NULL,
[TOTAL] [decimal](18, 2) NULL,
[DATE] [smalldatetime] NULL,
[LINE] [smallint] NULL,
[PSLIP] [nvarchar](10) NULL,
[VAT] [nvarchar](1) NULL,
[STORE] [nvarchar](3) NULL,
[STKSTR] [nvarchar](3) NULL,
[POST] [smalldatetime] NULL,
[PAID] [decimal](18, 2) NULL,
[WEIGHT] [decimal](18, 4) NULL,
[INSURE] [nvarchar](15) NULL,
[HAND] [decimal](18, 2) NULL,
[CODC] [decimal](18, 2) NULL,
[TOPAY] [decimal](18, 2) NULL,
[IND1] [nvarchar](1) NULL,
[IND2] [nvarchar](1) NULL,
[IND3] [nvarchar](1) NULL,
[COST] [decimal](18, 2) NULL,
[REPC] [nvarchar](6) NULL,
[DISPATCH] [nvarchar](1) NULL,
[TILLNO] [nvarchar](2) NULL,
[USER] [nvarchar](6) NULL,
[RCOMM] [decimal](18, 2) NULL,
[DISP1] [nvarchar](1) NULL,
[DISP2] [nvarchar](7) NULL,
[PRNSEQ] [int] NULL,
[TIME] [nvarchar](20) NULL,
[ROUND] [decimal](18, 2) NULL,
[MESSAGE1] [nvarchar](50) NULL,
[MESSAGE2] [nvarchar](50) NULL,
[MESSAGE3] [nvarchar](50) NULL,
[PRINT] [nvarchar](1) NULL,
[PDATE] [smalldatetime] NULL,
[FILENO] [nvarchar](20) NULL,
[sched6] [nvarchar](1) NULL,
[BUYACC] [nvarchar](10) NULL,
[DBCLW] [nvarchar](20) NULL,
[PRINTCODE] [nvarchar](3) NULL,
[INV_HOLD] [nvarchar](1) NULL,
[CURRATE] [decimal](18, 4) NULL,
[CURCODE] [nvarchar](3) NULL,
[DEPOS] [smalldatetime] NULL,
[ROUTE] [nvarchar](5) NULL,
[DEL_METHOD] [nvarchar](1) NULL,
[DROPNO] [int] NULL,
[SEATNO] [int] NULL,
[DDATE] [smalldatetime] NULL,
[COMM] [nvarchar](20) NULL,
[ROT] [nvarchar](1) NULL,
[KNAPP] [nvarchar](1) NULL,
[OSEC] [nvarchar](1) NULL,
[OSECT] [nvarchar](3) NULL,
[UPDEXT] [nvarchar](1) NULL,
[EORDREFNO] [nvarchar](32) NULL,
[FSI] [nvarchar](1) NULL,
[MESSAGE_LINES] [nvarchar](500) NULL) 

Este é o índice:

CREATE INDEX [Index_1] ON table_1 
([PRINT], [DEL_METHOD], [TYPE], [INV_NO], [DBINVHDID], [OSECT], [OSEC]) 
INCLUDE 
( [BUYACC], [CR_TERMS], [DISP1], [NAME], [ROUTE], [SEATNO], [STORE]) 

Esta é a consulta:

SELECT 
    [DBINVHDID],[STORE], [INV_NO], [DISP1],[SEATNO], [BUYACC],
    [NAME],[ROUTE], [CR_TERMS], [DEL_METHOD] 
FROM table_1 
WHERE 
    [PRINT] = 'N' 
    AND ([TYPE] = '3' OR [TYPE]='5') 
    AND [DEL_METHOD] = 'C' 
    AND [OSECT] <> 'KNP' 
    AND [OSEC] <> '1' 
ORDER BY [INV_NO] ASC

O plano de consulta:

O problema que tenho é que existe um predicado SEEK e um PREDICATE nas desigualdades:

Como posso recriar esse índice para que não haja predicado residual?

Inicialmente, o índice foi criado com as colunas OSECT e OSEC mais à esquerda na definição, o que causou avisos de E/S residuais e muitas leituras - então movi essas colunas para depois das colunas de igualdade que esclareceram os problemas de E/S.

O que estou tentando entender é como posso obter esse índice para satisfazer completamente a consulta sem um predicado residual?

A consulta pode ser reescrita?

Além disso, há um aviso de concessão de memória excessiva - SQL está alocando muita memória para esta consulta - STATS estão atualizadas com FULLSCAN

A concessão excessiva está relacionada ao predicado residual?

Eu tenho tentado me livrar de pesquisas caras no meu plano de consulta, mas não consigo entender isso. Eu entendo a ideia de criar um índice de cobertura para eliminar a necessidade de pesquisas, mas não sei como abordá-lo com um plano complicado como este.

Quaisquer idéias sobre como abordar isso seriam realmente apreciadas.

O plano de consulta pode ser encontrado aqui: https://www.brentozar.com/pastetheplan/?id=HyBbQ0eRr

Obrigado

Estou precisando de um pouco de ajuda.

Eu executei sp_Blitz em um dos meus SQL Servers e um dos resultados que ele retornou é "1531 planos estão presentes para uma única consulta no cache do plano - o que significa que provavelmente temos problemas de parametrização".

Eu segui o link no resultado.

Em seguida, executei sp_BlitzCache @ExpertMode = 1 para localizar consultas com vários planos, mas as colunas #Plans e #Distinct Plans retornam o valor 1 para todas as linhas.

Como faço para isolar a única consulta que tem vários planos?

Ambiente: SQL 2012 SP3 CU8

sp_BlitzCache versão 5.7