Início / dba / Perguntas / 156012
Accepted
Roman Starkov
Asked: 2016-11-23 03:11:40 +0800 CST

Como diagnosticar try_parse sendo muito lento?

  • 772

Eu tinha uma consulta muito grande que rodava mais devagar do que eu pensava, mas nenhuma pesquisa no plano de execução da consulta ajudou a esclarecer a lentidão. Eventualmente, eu reduzi: try_parseera o culpado!

consulta normal:

SELECT CloseDate
FROM MyTable

(4959 row(s) affected)

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 17 ms.

Com try_parse:

SELECT try_parse(CloseDate as datetime using 'en-us')
FROM MyTable

(4959 row(s) affected)

SQL Server Execution Times:
   CPU time = 719 ms,  elapsed time = 718 ms.

O plano de execução no último caso parece bastante inocente:

insira a descrição da imagem aqui

Existe uma maneira de identificar o culpado mais facilmente no futuro? A fonte real de lentidão está completamente oculta.

sql-server sql-server-2012

2 respostas

  1. Best Answer

    Tempo de CPU = 719 ms, tempo decorrido = 718 ms.

    Mostra que isso é limitado pela CPU.

    Se você puder reproduzir o problema em uma máquina de desenvolvimento, uma maneira de ver em que a CPU está gastando tempo é usar o Windows Performance Recorder.

    Depois de rastrear por alguns segundos enquanto o seguinte estava sendo executado simultaneamente ...

    SET nocount ON;

DECLARE @d DATETIME

WHILE 1 = 1
  SELECT @d = try_parse(NAME AS DATETIMEusing 'en-us')
  FROM   master..spt_values

    ... Entendo (clique para embiggen)

    insira a descrição da imagem aqui

    Ao SQL Server são atribuídos 20,88% do tempo total de CPU durante esse período. Mais de 75% desse montante é tomado com

    SqlAccess.dll!System.Data.SqlServer.Internal.SqlParseIntrinsicImpl::<ParseSsDate>
SqlAccess.dll!System.Data.SqlServer.Internal.SqlAppDomain::ExecuteExtension

    Com um pedaço saudável disso ocupado com

    clr.dll!IL_Throw
mscorlib.ni.dll!System.DateTimeParse.GetDateTimeParseException(System.DateTimeResult ByRef)

    Nenhum dos nomes master..spt_valuesfoi analisado como datas válidas, então todos acabam retornando nulo.

    O exposto acima mostra que, por algum motivo TRY_PARSE, chama o DateTime.Parsemétodo e captura a exceção, em vez de usar o TryParsemétodo interno que provavelmente teria um desempenho melhor nesse caso.

    • 5

  2. Nunca é tão simples. Você realmente tem que tentar várias maneiras de executar a consulta e verificar as diferenças. Não apenas verificando os tempos de execução, mas passando o mouse sobre cada etapa do plano de execução e verificando os custos.

    • 0

relate perguntas