Início / dba / Perguntas / 320749
Accepted
Don
Asked: 2022-12-09 16:17:13 +0800 CST

O pré-crescimento do tempdb pode prejudicar o desempenho?

  • 772

No final da tarde de ontem, adicionei 4 arquivos de dados tempdb aos 4 existentes, totalizando 8 (16 processadores no servidor SQL). Eu também os pré-aumentei para quase 100% do espaço disponível.

Hoje fui contatado por um de nossos desenvolvedores informando que ontem ela estava executando uma consulta que retornaria um conjunto inicial de resultados para a exibição do ssms em 3 a 5 segundos e toda a consulta seria concluída em 2 a 3 minutos. Hoje, a consulta leva 5 minutos para ser concluída e nenhum resultado é exibido em ssms por cerca de 2,5 minutos.

Não havia outras consultas em execução no momento. O uso da CPU foi baixo. Eu devolvi o servidor e não houve melhora. Agora, estou me perguntando se minha alteração no tempdb causou a diminuição no desempenho. Não consigo ver como, mas a paranóia está se instalando. Executei a consulta e monitorei o tempdb durante a execução e não parecia usar o tempdb, o que acho estranho, pois tem uma instrução GROUP BY que acredito usar tempdb. A tabela contém cerca de 22 milhões de linhas e a consulta retorna cerca de 7,8 milhões.

    select
      DATEADD(q, DATEDIFF(q, 0, MonthOfDate), 0) as Quarter
      ,[PartnerCD]
      ,[PartnerNM]
      ,[PartnerGRP]
      ,[BizMemberID]
      ,[MemberID]
      ,[BizType]
      ,[RateCD]
      ,[Rate]
      ,sum([MemberMonth]) as MemberQuarter
      ,[CurrentAge]
      ,[AgeAtTime] = CASE WHEN dbo.fn_CalculateAge(BirthDT, (DATEADD(q, DATEDIFF(q, 0, MonthOfDate), 0)), 'YEAR') < 0 THEN NULL ELSE dbo.fn_CalculateAge(BirthDT, (DATEADD(q, DATEDIFF(q, 0, MonthOfDate), 0)), 'YEAR') END
      ,AgeCategory = dbo.fn_CalculateAgeCatYrsOrdered(BirthDT, (DATEADD(q, DATEDIFF(q, 0, MonthOfDate), 0)))
      ,[BirthDT]
      ,[ZipCD]
FROM [Partner].[dbo].[Membership]  
group by DATEADD(q, DATEDIFF(q, 0, MonthOfDate), 0)
      ,[PartnerCD]
      ,[PartnerNM]
      ,[PartnerGRP]
      ,[BizMemberID]
      ,[MemberID]
      ,[BizType]
      ,[RateCD]
      ,[Rate]
      ,[CurrentAge]
      ,[BirthDT]
      ,[ZipCD]

É provável que minha alteração tenha causado a diminuição do desempenho ou provavelmente é coincidência?

sql-server-2019

1 respostas

  1. Best Answer

    No entanto, reiniciei os serviços SQL depois de fazer a alteração. Eu pensei que era a ação adequada a ser tomada depois. Acho que talvez isso possa fazer com que a consulta crie um plano de execução novo e menos eficiente.

    Bingo. É por isso que adicionei especificamente essa cláusula em meu comentário.

    Quando você reinicia o serviço do SQL Server (ou o próprio servidor, que obviamente também reinicia o serviço), o cache do plano de consulta é limpo, conforme mencionado na resposta de Aaron Bertrand à minha pergunta sobre o assunto . Isso significa que o plano de consulta que foi armazenado em cache anteriormente para sua consulta em questão agora foi apagado e quando sua instância do SQL Server foi gerar um novo plano (com base em vários fatores com as tabelas em jogo, como elas são indexadas, e como as estatísticas dos dados mudaram desde o plano anterior) acabou com um plano diferente que parece ser menos eficiente.

    Você pode limpar o plano de consulta problemático do cache do plano usando DBCC FREEPROCCACHE (the_plan_handle_of_the_bad_plan). Consulte este exemplo dos documentos sobre como obter o identificador de plano para esse plano de consulta específico. Executar novamente a consulta gerará novamente um novo plano que pode ou não acabar sendo o mesmo plano. Se acabar sendo o mesmo, então seu melhor curso de ação é realmente solucionar os gargalos de desempenho que devem ser evidentes no próprio plano de execução real.

    • 0

relate perguntas