D-K's questions

Estou usando o procedimento de armazenamento sp_BlitzCache de Brent Ozar e estou tentando descobrir por que ele está relatando:

"Algo em seu plano está forçando uma consulta em série. Uma investigação mais aprofundada é necessária se isso não for planejado."

Após investigação, descobri que a configuração do servidor foi definida:

'Max Degree of Parallelism = 1' 

(Isso está na minha lista para configurar corretamente. É um resquício de dias de ignorância.)

Isso está definindo a causa do Brent para relatar a serialização forçada?

Para um sistema de relatórios ETL, é normal que o tempo total de execução de um pull de 15 minutos sem dados seja semelhante a um pull de 24 horas com dados?

Eu esperava que o tempo total para ETL quando não há dados fosse menor, mas essa não é a situação entre um pull de 15 minutos e 24 horas. Mas devo confessar que não sei nada sobre as partes internas das fases T e L dentro de um servidor de relatório.

Alguém pode esclarecer se as fases T e L são tipicamente fixas em duração (até certo ponto)?

Reconheço que a experiência e as habilidades de cada um são diferentes. Dito isso, quero evitar criar expectativas muito altas (ou muito baixas) para um DBA que por meio de ações; parece ser um 'administrador'.

Dado:

• Sou um desenvolvedor que está se aprofundando na solução de problemas e problemas de desempenho do SQL Server. À noite estou assistindo a vídeos de Brent Ozar com um balde de pipoca.
• Uma empresa com várias divisões, esta divisão com cerca de 100 membros da equipe
• Muitos clientes com bancos de dados com milhões de linhas com ETL
• Uma pequena equipe de DBA que é esticada para lidar com esses mesmos clientes. Lide com problemas de HAG, backup, restaurações, crie novas implantações para clientes novos ou atualizados.

NÃO estou tentando justificar minha própria opinião. Desejo ajustar minha opinião ou de outras pessoas na empresa.

Pergunta:

Diante do exposto, deve-se esperar que um DBA seja simplesmente um 'administrador'? Isso é algo que você normalmente já viu?

Entrei nesta novela (veja minhas outras perguntas recentes) com a expectativa de que um DBA seja 'esperado' para mergulhar fundo. Cheguei a acreditar que entendi mal e estou inclinado para um DBA - ser um 'administrador'.

Congratulo-me com as experiências de outros e talvez conselhos para refinar esta questão.

É OPTION (RECOMPILE)usado na produção?

Esta opção parece ter um monte de má imprensa. É merecido?

Tenho um DBA que, até o momento, não é fã da ideia de OPTION (RECOMPILE)dentro da carne do Report ETL ssis agent querys. Essas consultas são executadas (até onde eu sei) sequencialmente e em intervalos programados.

Histórico de volta:

• SQL Server 2016
• Consultas ETL que causam varreduras de índice clusterizado quando executadas por meio do agente ssis. Essas consultas levam minutos para serem concluídas e causam grande impacto.
• A mesma consulta e parâmetro executados por meio de procedimentos armazenados locais são executados em menos de um segundo.

Espere você tem certeza que OPÇÃO (RECOMPILAR) é a resposta?

• Desconhecido.
• Mas eu preciso saber se isso é realmente uma má ideia antes de tentar.

Os riscos que conheço:

• Houve pelo menos dois bugs sérios no passado relacionados a OPTION (RECOMPILE). Duas consultas executadas ao mesmo tempo podem trocar conjuntos de resultados. Eca !! https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-or-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241

Então, dado o acima - esta opção é realmente usada no mundo real? É aceitável que eu recomende (e teste) isso como uma opção para um ambiente de produção?

Pediram-me para fornecer mais detalhes. Eu mencionei que eu tenho outros posts todos relacionados a este tópico. Deixe-me dar mais informações sobre isso:

• O problema principal é que as consultas provenientes de um servidor de aplicativos estão demorando mais de 60 segundos. Normalmente, essas consultas levam de 4 a 10 segundos. Com muita dor, determinei que os tempos limite se alinham com as consultas ETL. 4 consultas de 15 para ser específico.
• Um contribuinte para o problema é encontrado nos servidores de aplicativos. Especificamente, o nível de isolamento é definido serializabledentro da camada de hibernação; que aprendi não é ideal para ambientes de produção de alto volume.

Deixe-me compartilhar as outras perguntas:

SQL Server - Posso remover cirurgicamente um plano de consulta em cache incorreto ou estou perseguindo a ideia errada?

Por que a consulta no ETL via SSIS é lenta, mas por meio de um procedimento armazenado local é rápida?

Estou vendo o clássico problema 'executa rápido no gerenciador de estúdio, mas lento no aplicativo'. Parece que pode ser sniffing de parâmetros. No entanto, minha experiência com ETL e SSIS é zero.

Do DBA recebi a seguinte consulta e ela termina com um ? em vez de um parâmetro. Aqui está uma amostra ofuscada da consulta:

SELECT 
tablex.x_id, 
tablex.create_ts, 
tablex.update_ts, 
tablex.myStatus, 
tablex.x_type, 
tablex.ami_uploaded, 
tablex.work_id,
tablex_capture_ts,
[column1],
[column2],
[column3],
[column4] 
FROM     sqltable..tablex 
INNER JOIN 
sqltable..tableWork ON tablex.work_id = tableWork.work_id
WHERE  
(tablex.update_ts >= ?)

• De acordo com o DBA, o ponto de interrogação é substituído por um argumento de 'hora/data' que está uma hora no passado.
• Quando executo essa mesma consulta localmente a partir de um procedimento armazenado, passando um parâmetro que está há uma hora, ele retorna em menos de um segundo. (o que para mim significa que 'pode' usar o índice existente)
• Observando esta execução a partir do ETL, leva alguns minutos e o plano de execução mostra as varreduras de tabela.
• Existe um índice update_ts.

O mecanismo de consulta recomenda um segundo índice update_ts com várias colunas de inclusão. Eu gostaria de evitar isso, se possível, pois aumentará a pressão da memória e não estou convencido de que isso resolva o problema real. Pensamentos?

Isso parece um caso em que as estatísticas de consulta estão distorcidas e, quando o mecanismo de consulta detecta o parâmetro, ele evita usar o índice existente porque o número estimado de linhas está além do limite.

Minhas perguntas:

1. Como o ? na consulta SSIS são tratadas pelo sql server? Eu sei que o sniffing de parâmetros é uma questão complexa. Eu tenho estudado isso: http://www.sommarskog.se/query-plan-mysteries.html
2. Se for o mecanismo de consulta farejando o parâmetro (de uma hora no passado) e pensando que o número estimado de linhas está além do ponto de disparo, o que faço para corrigir isso? O DBA recusou a dica OPTIMIZE for RECOMPILE como uma opção e não posso dizer que discordo. (Ele tem um ponto em relação ao histórico de bugs) No entanto, essas consultas acontecem SOMENTE do ETL nos horários programados e talvez isso seja motivo suficiente para usar o HINT independente do possível bug??

Além disso, este é um longo problema com o qual tenho lutado. Todas essas postagens estão relacionadas a esse mesmo problema. Que viagem de descoberta:

Este é um tempo de 'Bloqueio' excessivamente grande e é indicativo de um problema?

SQL Server - Posso remover cirurgicamente um plano de consulta em cache incorreto ou estou perseguindo a ideia errada?

Qualquer conselho é muito apreciado.

Este deve ser o plano de execução real da versão do procedimento armazenado local. Esta versão retorna em 1 segundo e exibe o comportamento QUE EU DESEJO que o ETL tenha:

https://www.brentozar.com/pastetheplan/?id=ry4wy6dBO

Agora, esta é uma captura de tela da versão ETL que leva minutos para ser concluída. Desculpe, não posso fornecer mais detalhes sobre esta consulta específica:

Esta é uma captura de tela de um rastreamento de perfil feito durante um período de uma hora. Acho que é assim que os comandos ETL estão sendo executados. Eu ainda não sei porque todos têm o mesmo tempo. Eu também preciso encontrar o preparar também. Olhe para essas colunas de CPU, leituras e duração!

Dado:

• Ambiente de produção
• Servidores de aplicativos usando o Hibernate
• SQL Server Studio Manager v17.5
• SQL Server 2016 em uma configuração de HAG em cluster
• SQL Servers NÃO têm o recurso Repositório de Consultas habilitado
• O autor desta pergunta é um engenheiro de software com conhecimento suficiente do SQL Server para ser categorizado como principalmente inofensivo

atualização 1

• Configurações de crescimento do banco de dados: Ilimitado, 1024.000 KB, somente dados
• instant_file_initialization_enabled - Sim
• is_auto_update_stats_async_on - Não

atualização 2

• O servidor tem 4 núcleos de CPU
• Há picos de tarefas em espera de mais de 3.000.000. Ainda não faço ideia do que sejam. Este deve ser o motivo dos grandes tempos de 'bloqueio'.
• Esses picos ocorrem a cada 10 ou 15 segundos. Eu tenho o seguinte gráfico atualizando uma vez por segundo:

O problema:

A raiz do problema é que, em momentos aparentemente aleatórios de um dia agitado, algumas consultas SQL expiram, no entanto, para os propósitos desta pergunta, estou interessado em saber se a captura de tela é indicativa de um problema em si. Talvez isso seja subjetivo, mas não tenho experiência com esse valor.

Ação:

As falhas em si não apontam diretamente para uma questão concreta e, portanto, estou reunindo evidências e tentando um processo de eliminação sempre que possível. Atualmente estou investigando se tempos de espera excessivos e uma 'tempestade perfeita' de consultas podem causar uma cascata de bloqueios e, portanto, um tempo limite de consulta.

Evidências Recolhidas:

• Várias consultas estão resultando em varreduras completas de índice ou varreduras completas de tabela.
• Várias capturas de tela com planos de execução mostrando varreduras de tabela. A inspeção superficial mostra que os índices existem - ainda não usados. Eu posso ser capaz de higienizar as capturas de tela se elas forem úteis.
• A captura de tela abaixo mostra um grande tempo de espera.

Pergunta:

Que outras informações ajudariam a determinar se os tempos de bloqueio e espera podem ser a causa dos tempos limite de consulta? Por exemplo, eu tenho a seguinte captura de tela do monitor de atividade do gerenciador de estúdio do sql server. O valor me pareceu surpreendente.

Preciso de ajuda para entender minhas opções. Dado:

• Configuração de cluster do SQL Server que é mantida por um DBA.
• O sistema ainda NÃO está em produção (não foi entregue ao cliente).
• Push inicial de alto volume de dados que NÃO tem interrupções por dias
• Posso parar e iniciar o push de dados e alterar o banco de dados a qualquer momento. Basicamente eu posso parar todas as entradas.

Eu recomendo ao nosso DBA que mudemos para o modo simples porque estamos vendo dentro do monitor de atividade uma pilha de consultas em estado de espera que eventualmente causa erros para os servidores de aplicativos.

Nunca tive esse problema antes e em processo de eliminação vejo que estamos no modo de recuperação FULL ao invés de SIMPLE.

Pedi para mudarmos para SIMPLE de FULL e esta é a resposta que recebo. Existe outra opção que talvez o DBA não esteja ciente?

Como posso ajudar?

"Não podemos mudar para simples usando AlwaysOn no SQL."

Posso desativar o AlwaysOn para a fase de carregamento inicial ou estou sem sorte?

--- Adição ----

Deixe-me preparar o palco:

• SQL Server > 2016
• Vários bancos de dados com os mesmos esquemas
• Os dados são semelhantes, mas não idênticos
• Os mesmos índices existem etc., todos os sistemas, exceto um, funcionam como esperado
• O exame do plano de execução recomenda a criação de um índice com TODAS as colunas como INCLUDE. A mesma coluna base já existe sem as inclusões.

O problema:

• Em UM dos bancos de dados, o mecanismo de consulta não utiliza um índice existente e usa uma verificação completa da tabela
• Executando manualmente a consulta (que usa um parâmetro) - varredura completa da tabela!
• Executando manualmente a consulta sem um parâmetro (data fixa usada) - usa o índice.
• Executando manualmente a consulta com um parâmetro e adicionando WITH (INDEX(update_ts_INDEX))- usa o índice. A consulta vai de 2 minutos a menos de um segundo.

Hipótese:

• Acredito que o cache de consulta possa estar corrompido - mas não sei se isso é possível. Por comércio, sou um desenvolvedor java que passou os últimos 3 anos investigando o ajuste de desempenho do servidor SQL, etc.
• O fato de executar manualmente a consulta sem um parâmetro - o mecanismo de consulta escolhe o índice certo - me impressiona. Ideias?

Notas:

• Nos outros servidores, que executam o mesmo código e consultas, não consigo encontrar nenhuma evidência de que essa mesma consulta esteja demorando. Eles devem estar usando o índice.
• Acabei de executar o comando manualmente, em outra região com um parâmetro, e ele usou o índice, então o problema está de fato em APENAS uma região - um banco de dados.

Exemplo de consulta:

DECLARE @P1 DATETIME = GETDATE() - .1;

SELECT value_1, update_ts, value_2 FROM PRODUCTION_TABLE 
WHERE (PRODUCTION_TABLE.update_ts > @P1);

Se eu remover a variável e codificar manualmente uma data, ela usará o index.

Pergunta: Posso remover cirurgicamente um plano de consulta em cache incorreto para essa consulta específica?

--- ATUALIZAR ---

O uso OPTION (RECOMPILE)faz com que o mecanismo de consulta escolha o índice correto.

Dado o seguinte SQL, o que "ONLY", "OPERATOR(pg_catalog.=)" e "FOR KEY SHARE" fazem?

SELECT 1 
FROM ONLY "public"."acmeinstanceinfo" x 
WHERE "widgetid" OPERATOR(pg_catalog.=) $1 
FOR KEY SHARE OF x

Eu tenho uma boa experiência com o servidor Microsoft SQL, mas zero com o PostgreSQL. Qualquer insight sobre o que essa consulta está fazendo seria ótimo.

Eu tenho 30 milhões de linhas dentro de um banco de dados sql server onde adicionei uma coluna de marcação simples. Um caractere permitindo null. Eu adicionei um índice para a coluna.

Eu o uso para acompanhar quais linhas foram processadas para uma extração de dados. Durante o desenvolvimento inicial estarei reiniciando o processo de extração do zero (várias vezes) e preciso redefinir o valor para '1'.

Sendo um desenvolvedor de banco de dados neófito (quem estou brincando...), minha primeira tentativa usou um script de atualização simples para redefinir o valor de '2' (o que processei esta linha) para '1'. A primeira vez que executei o script, ele foi executado em cerca de 5 minutos. A última vez que executei - levou 45 minutos. Tem que haver uma maneira melhor.

É possível acelerar isso removendo completamente a coluna e recriando-a com um valor padrão de '1'? A velocidade permanecerá consistente?

-- ATUALIZAR ---

Na próxima vez que precisar fazer isso, tentarei o seguinte:

ALTER TABLE acmewidgets DROP COLUMN LegacyExtract;
ALTER TABLE acmewidgets
        ADD LegacyExtract CHAR NOT NULL DEFAULT (1);