Desempenho ruim do SQL Server 2016 Enterprise

Desculpe demorar, mas quero fornecer o máximo de informações possível, para que possa ser útil para a análise.

Sei que existem várias postagens com problemas semelhantes; no entanto, eu já acompanhei essas várias postagens e outras informações disponíveis na Web, mas o problema permanece.

Estou com um sério problema de desempenho no SQL Server que está deixando os usuários loucos. Esse problema se prolonga por vários anos, e até o final de 2016 era gerenciado por outra entidade e a partir de 2017 passou a ser gerenciado por mim.

Em meados de 2017, consegui resolver o problema seguindo as dicas de indexação indicadas pelos Relatórios do Painel de Desempenho do Microsoft SQL Server 2012. O efeito foi imediato, parecia mágica. O processador que estava nos últimos dias quase sempre nos 100% tornou-se super sereno e o feedback dos usuários foi retumbante. Até o nosso técnico de ERP ficou encantado, pois normalmente levava 20 minutos para obter determinadas listagens e, finalmente, ele conseguia fazê-lo em segundos.

Com o tempo, no entanto, lentamente começou a piorar. Evitei criar mais índices, por medo de que muitos índices piorassem o desempenho. Mas em algum momento eu tive que apagar os que não tinham utilidade e criar os novos que o Performance Dashboard me sugere. Mas sem impacto.

A lentidão sentida é essencialmente ao salvar e consultar, no ERP.

Eu tenho um Windows Server 2012 R2 dedicado ao SQL Server 2016 Enterprise (64 bits) com a seguinte configuração:

• CPU: Intel Xeon CPU E5-2650 v3 a 2.30GHz
• Memória: 84 GB
• Em termos de armazenamento, o servidor possui um volume dedicado ao sistema operacional, outro dedicado aos dados e outro dedicado aos logs.
• 17 bases de dados
• Comercial:
  • No maior banco de dados estão conectados mais ou menos 113 usuários simultaneamente
  • Em outro, existem cerca de 9 usuários
  • Em dois deles são 3 + 3
  • O restante tem apenas 1 usuário cada
  • Temos uma web que também grava para um banco de dados maior, mas onde o uso é muito menos regular e deve ter cerca de 20 usuários.
• Tamanho dos DBs:
  • O maior dos bancos de dados possui 290 GB
  • O segundo maior tem 100 GB
  • O terceiro maior tem 20 GB
  • Os quarto 14 GB
  • O restante tem pouco mais de 3 GB cada

Essa é a instância de produção, mas também temos uma instância de desenvolvimento que acredito que pode ser desconsiderada para esse fim, porque na maioria das vezes eu sou a única conexão lá, mas esse problema ocorre constantemente, mesmo quando não estou conectado .

O processador é quase sempre assim:

Temos rotinas que são executadas durante a noite (não problemáticas) e algumas que são executadas durante o dia.

Os usuários se conectam pela Área de Trabalho Remota a outras máquinas configuradas pelo ODBC 32 para acessar o SQL Server.

O Datacenter onde os servidores estão localizados tem 100/100 Mbps, bem como onde eu estou. A maioria dos sites é vinculada pelo MPLS e outros pelo IPSec (de FO a 4G). O fornecedor fez muitas análises e o circuito está ok.

A taxa de acertos do cache é de 99% (solicitações de usuário e sessões de usuário)

As esperas são assim:

Já coletei dados com o Perfmon e tenho os resultados, se isso ajudar na sua análise - pessoalmente, não tirei nenhuma conclusão da análise.

Conto com o seu apoio para resolver esse problema, estando disponível para fornecer as informações que você considera necessárias para a resolução.

Muito obrigado.

Aqui está a remarcação sp_blitz (substituí os nomes das empresas por pseudônimos):

Prioridade 1: Confiabilidade :

• Último bom DBCC CHECKDB com mais de 2 semanas

  • mestre

  • modelo - Último sucesso CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - Último sucesso CHECKDB: 2018-02-07 15: 04: 27.740

Prioridade 10: Desempenho :

• CPU com número ímpar de núcleos

  • O nó 0 possui 5 núcleos atribuídos a ele. Essa é uma configuração NUMA muito ruim.

  • O nó 1 possui 5 núcleos atribuídos a ele. Essa é uma configuração NUMA muito ruim.

Prioridade 20: Configuração do arquivo :

• TempDB na unidade C tempdb - O banco de dados tempdb possui arquivos na unidade C. O TempDB cresce frequentemente de maneira imprevisível, colocando o servidor em risco de ficar sem espaço na unidade C e travar bastante. C também costuma ser muito mais lento que outras unidades, portanto o desempenho pode estar sofrendo.

Prioridade 50: Confiabilidade :

• Erros registrados recentemente no rastreamento padrão
  • master - 2018-03-07 08: 43: 11.72 Erro de logon: 17892, Gravidade: 20, estado: 1. 2018-03-07 08: 43: 11.72 O logon falhou no logon 'example_user' devido à execução do acionador. [CLIENTE: IPADDR]

(observação: muitos erros como esse devido a um acionador ativado que limita as sessões do usuário - para controle de uso de licenciamento do ERP)

• A verificação da página não é a ideal

  • DATABASE_A - O banco de dados [DATABASE_A] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_B - O banco de dados [DATABASE_B] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_C - O banco de dados [DATABASE_C] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_D - O banco de dados [DATABASE_D] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_E - O banco de dados [DATABASE_E] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_F - O banco de dados [DATABASE_F] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_G - O banco de dados [DATABASE_G] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_H - O banco de dados [DATABASE_H] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_I - O banco de dados [DATABASE_I] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_Z - O banco de dados [DATABASE_Z] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_K - O banco de dados [DATABASE_K] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_J - O banco de dados [DATABASE_J] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_L - O banco de dados [DATABASE_L] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_M - O banco de dados [DATABASE_M] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_O - O banco de dados [DATABASE_O] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_P - O banco de dados [DATABASE_P] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_Q - O banco de dados [DATABASE_Q] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_R - O banco de dados [DATABASE_R] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_S - O banco de dados [DATABASE_S] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_T - O banco de dados [DATABASE_T] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_U - O banco de dados [DATABASE_U] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_V - O banco de dados [DATABASE_V] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

  • DATABASE_X - O banco de dados [DATABASE_X] possui NONE para verificação da página. O SQL Server pode ter mais dificuldade em reconhecer e se recuperar de corrupção de armazenamento. Considere usar CHECKSUM.

• DAC remoto desativado - O acesso remoto ao DAC (Dedicated Admin Connection) não está ativado. O DAC pode facilitar muito a solução de problemas remotos quando o SQL Server não responde.

Prioridade 50: Informações do servidor :

• Inicialização instantânea de arquivos não ativada - considere ativar o IFI para restaurações mais rápidas e aumento de arquivos de dados.

Prioridade 100: Desempenho :

• Fator de preenchimento alterado

  • DATABASE_A - O banco de dados [DATABASE_A] possui 417 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_B - O banco de dados [DATABASE_B] possui 318 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_C - O banco de dados [DATABASE_C] possui 346 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_D - O banco de dados [DATABASE_D] possui 663 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_E - O banco de dados [DATABASE_E] possui 335 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_F - O banco de dados [DATABASE_F] possui 1705 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_G - O banco de dados [DATABASE_G] possui 671 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_H - O banco de dados [DATABASE_H] possui 2364 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_I - O banco de dados [DATABASE_I] possui 1658 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_Z - O banco de dados [DATABASE_Z] possui 673 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_K - O banco de dados [DATABASE_K] possui 312 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_J - O banco de dados [DATABASE_J] possui 864 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_L - O banco de dados [DATABASE_L] possui 1170 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_M - O banco de dados [DATABASE_M] possui 382 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_O - O banco de dados [DATABASE_O] possui 356 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • msdb - O banco de dados [msdb] possui 8 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_P - O banco de dados [DATABASE_P] possui 291 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_Q - O banco de dados [DATABASE_Q] possui 343 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_R - O banco de dados [DATABASE_R] possui 2048 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_S - O banco de dados [DATABASE_S] possui 325 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_T - O banco de dados [DATABASE_T] possui 322 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_U - O banco de dados [DATABASE_U] possui 351 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_V - O banco de dados [DATABASE_V] possui 312 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • DATABASE_X - O banco de dados [DATABASE_X] possui 352 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

  • tempdb - O banco de dados [tempdb] possui 2 objetos com fator de preenchimento = 70%. Isso pode causar problemas de desempenho de memória e armazenamento, mas também pode impedir a divisão de páginas.

• Muitos planos de planos para uma consulta - 20763 estão presentes para uma única consulta no cache do plano - o que significa que provavelmente temos problemas de parametrização.

• Acionadores de servidor ativados - O acionador de servidor [connection_limit_trigger] está ativado. Certifique-se de entender o que esse gatilho está fazendo - quanto menos trabalho ele fizer, melhor.

• Procedimento armazenado COM RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] possui WITH RECOMPILE no código do procedimento armazenado, o que pode causar um aumento no uso da CPU devido a constantes recompilações do código.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] possui WITH RECOMPILE no código do procedimento armazenado, o que pode causar aumento no uso da CPU devido a recompilações constantes do código.

Prioridade 110: Desempenho :

• Tabelas ativas sem índices agrupados

  • DATABASE_A - O banco de dados [DATABASE_A] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_B - O banco de dados [DATABASE_B] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_C - O banco de dados [DATABASE_C] possui heaps - tabelas sem um índice clusterizado - que estão sendo consultados ativamente.

  • DATABASE_E - O banco de dados [DATABASE_E] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_F - O banco de dados [DATABASE_F] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_H - O banco de dados [DATABASE_H] possui heaps - tabelas sem um índice clusterizado - que estão sendo consultados ativamente.

  • DATABASE_I - O banco de dados [DATABASE_I] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_K - O banco de dados [DATABASE_K] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_O - O banco de dados [DATABASE_O] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_Q - O banco de dados [DATABASE_Q] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_S - O banco de dados [DATABASE_S] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_T - O banco de dados [DATABASE_T] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_U - O banco de dados [DATABASE_U] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_V - O banco de dados [DATABASE_V] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

  • DATABASE_X - O banco de dados [DATABASE_X] possui heaps - tabelas sem um índice em cluster - que estão sendo consultados ativamente.

Prioridade 150: Desempenho :

(Observação: muitos conselhos aqui, mas não os pude incluir por causa da limitação de caracteres. Se houver outra maneira de compartilhar, indique.)

Você nos fez uma pergunta longa (e muito detalhada). Agora você tem que lidar com uma resposta longa. ;)

Há várias coisas que eu sugeriria mudar no seu servidor. Mas vamos começar com a questão mais urgente.

Medidas de emergência únicas:

O fato de o desempenho ter sido satisfatório após a implantação dos índices em seu sistema e o desempenho lentamente degradante é uma dica muito forte de que você precisa começar a manter suas estatísticas e (em menor grau) cuidar da framentação do índice.

Como medida de emergência, eu sugeriria uma atualização manual de estatísticas em todos os seus bancos de dados. Você pode obter o TSQL necessário executando este script:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

É fornecido por Tim Ford em seu post no blog mssqltips.com e ele também está explicando por que as estatísticas de atualização são importantes.

Observe que esta é uma tarefa intensiva de CPU e E / S que não deve ser realizada durante o horário comercial.

Se isso resolver o seu problema, por favor, não pare por aí!

Manutenção regular:

Veja o Ola Hallengren Maintenance Solution e configure pelo menos esses dois trabalhos:

• Um trabalho de atualização de estatísticas (se possível todas as noites). Você pode usar esse código CMD em seu trabalho de agente. Este trabalho deve ser criado do zero.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Um trabalho de manutenção de índice. Eu sugeriria começar com uma execução agendada uma vez por mês. Você pode começar com os padrões que o Ola fornece para o trabalho IndexOptimize.

Há várias razões pelas quais estou sugerindo o primeiro trabalho para atualizar as estatísticas separadamente:

• Uma reconstrução de índice atualizará apenas as estatísticas das colunas cobertas por esse índice, enquanto uma reorganização do índice não atualiza as estatísticas. Ola separa a fragmentação em três categorias. Por padrão, apenas os índices altos da categoria serão reconstruídos.
• As estatísticas para colunas não cobertas por um índice serão atualizadas apenas pelo trabalho IndexOptimize.
• Para mitigar o Problema Chave Ascendente .

O SQL Server atualizará automaticamente as estatísticas se o padrão for deixado ativado. O problema disso são os limites (menos um problema com o SQL Server 2016). As estatísticas são atualizadas quando uma certa quantidade de linhas é alterada (20% nas versões mais antigas do SQL Server). Se você possui tabelas grandes, pode haver muitas alterações antes da atualização das estatísticas. Veja mais informações sobre limites aqui .

Como você está executando CHECKDBs, tanto quanto posso dizer, você pode continuar fazendo isso como antes ou usar a solução de manutenção para isso também.

Para obter mais informações sobre fragmentação e manutenção de índice, consulte:

Visão geral da fragmentação de índice do SQL Server

Pare de se preocupar com a fragmentação do SQL Server

Considerando o seu subsistema de armazenamento, sugiro que não se fixe muito na "fragmentação externa" porque os dados não são armazenados em ordem na sua SAN de qualquer maneira.

Otimize suas configurações

O script sp_Blitz fornece uma excelente lista para começar.

Prioridade 20: Configuração de arquivo - TempDB na unidade C: fale com o administrador do armazenamento. Pergunte a eles se sua unidade C é o disco mais rápido disponível para o SQL Server. Caso contrário, coloque seu tempdb lá ... ponto final. Em seguida, verifique quantos arquivos temdb você possui. Se a resposta for uma, conserte isso . Se eles não forem do mesmo tamanho, corrija esses dois.

Prioridade 50: Informações do servidor - Inicialização instantânea de arquivos não ativada: siga o link que o script sp_Blitz fornece e ative o IFI.

Prioridade 50: Confiabilidade - Verificação da página não ideal: você deve definir isso de volta ao padrão (CHECKSUM). Siga o link que o script sp_Blitz fornece e siga as instruções.

Prioridade 100: Desempenho - Fator de preenchimento alterado: pergunte a si mesmo por que existem tantos objetos com fator de preenchimento definido como 70. Se você não tiver uma resposta e nenhum fornecedor de aplicativos a exigir estritamente. Defina de volta para 100%.

Isso basicamente significa que o SQL Server deixará 30% de espaço vazio nessas páginas. Portanto, para obter a mesma quantidade de dados (em comparação com 100% de páginas inteiras), seu servidor precisa ler 30% a mais de páginas e ocupará 30% mais de espaço na memória. O motivo disso geralmente é impedir a fragmentação do índice.

Mas, novamente, seu armazenamento está salvando essas páginas em diferentes partes de qualquer maneira. Então, eu configuraria de volta para 100% e a partir daí.

O que fazer se todo mundo estiver feliz:

• Veja o restante da saída do sp_Blitz e decida se você os altera conforme sugerido.
• Execute sp_BlitzIndex e verifique os índices que você criou, se eles são usados ​​ou onde pode haver uma oportunidade de adicionar / alterar um.
• Dê uma olhada nos dados da Query Store (como sugerido por Peter). Você pode encontrar uma introdução aqui .
• Aprecie a estrela do rock ao vivo que um DBA merece. ;)

Sem desconsiderar todas as suas respostas que foram muito úteis e que apliquei ou aplicarei, o maior problema não foi fácil de encontrar.

O problema piorou nos dias após nossas últimas mensagens.

Como estamos baseados na nuvem, nem eu nem a empresa que gerencia a infraestrutura e nos fornece suporte têm acesso aos hosts físicos.

Algo me fez pensar quando notei que em alguns dias o processador estava em média em 20% e em outros dias era muito maior, em mais de 60%, quando a carga de trabalho, embora nunca fosse exatamente a mesma, é semelhante. Há o mesmo número de pessoas executando mais ou menos o mesmo tipo de operações.

No início desta semana, os usuários começaram a ficar paralisados ​​por vários minutos e apenas o processador foi estrangulado. Pedi a vários usuários que desconectassem (aqueles que estavam gastando mais recursos, mas ainda nada fora do comum), desliguei vários serviços vinculados ao banco de dados e, no final, nada mudou. Perguntei ao administrador do sistema que nos suporta e que pode se comunicar com os caras da nossa nuvem para remotamente para minha máquina para ver o que estava vendo e para me ajudar a encontrar algo, porque não pude fazer melhor para encontrar o problema.

O técnico também não encontrou nada. Ele finalmente começou a me dar um motivo para que outra coisa estivesse causando esse problema e foi quando ele entrou em contato com a nuvem. Na nuvem, eles não perceberam nada, apenas porque, como há um balanceamento de carga configurado entre hosts físicos, a VM que suporta nosso SQL Server foi movida algumas vezes naquele dia entre hosts físicos. Felizmente, eu disse ao nosso técnico exatamente a que horas os problemas começaram a ocorrer naquele dia, o que coincidiu com o horário em que a VM foi movida pela última vez para um dos hosts físicos dos quais não saiu o resto do dia.

Se o técnico não tivesse acompanhado de perto esse problema, seria um daqueles momentos em que ele poderia falar com os caras da nuvem, mas quando eles viram amostras de desempenho, eles não receberiam nada, porque mais uma vez a nuvem só via amostras com CPU da ordem de 40/50%, quando na verdade estava acima de 80% e geralmente ficava em 100%.

Agora, a máquina está em um host físico (não se move entre os hosts) e, embora ainda não tenhamos alcançado o desempenho perfeito, todos estão trabalhando e dando muito mais feedback positivo, porque a CPU média é de cerca de 20% com todos os nossos usuários e Serviços.

Enquanto isso, também colocamos o tempdb em outro disco (estava no disco do sistema operacional) e aumentamos os arquivos, para estar mais de acordo com o número de núcleos das CPUs.

O número de núcleos também foi ajustado com base nas recomendações do sp_Blitz.

Havia também uma rotina automática que funcionava o dia inteiro com base em uma data antiga ... e como ela não terminava de manhã quando chegamos, e não temos como verificar se ela está funcionando ou não, eu ainda comecei a executar manualmente. Mas provavelmente o outro ainda estava correndo e estava correndo duas vezes durante esse período. Alteramos a data para reduzir o tempo necessário e agora é tarde da noite. Mas essa não era a solução, pois ela foi resolvida diante de muitos problemas que tivemos como o descrito aqui.

Também conseguimos que o assistente de ERP agendasse uma reunião com o fabricante, por isso vamos mostrar nosso sistema e procurar sugestões, além de esclarecer algumas dúvidas, pois existem recomendações nos vídeos de treinamento que são contrárias à maioria dos recomendações, incluindo a própria Microsoft, como Priority Boost on e Fill Factor 70%.

Como o aplicativo também possui uma tela de manutenção, procurarei a periodicidade necessária dessa manutenção e o que resta fazer fora do aplicativo. Minha idéia é usar os planos de Ola Hallengren.

Acredito que a resposta de Thomas Kronawitter esteja absolutamente correta e estou aplicando, no entanto, acho que essa descrição pode ser importante para outras pessoas que, depois de seguir todas as boas práticas, ainda não consegue resolver o problema, pois pode estar nos hosts físicos . Obrigado Thomas.