O SQL Sentry Plan Explorer conta as leituras em UDFs?

Eu tenho uma consulta como esta:

select dbo.fn_complexFunction(t.id)
from mytable t

No SQL Sentry Plan Explorer, notei que preciso executar o Get Estimated Plan no SQL Sentry para fazer com que o Query Plan inclua a UDF.

Ao executar 'Obter plano atual', não parece que as leituras lógicas e outras métricas incluem as operações que ocorrem no UDF. Em casos como esse, é a única solução alternativa para usar o Profiler?

Isenção de responsabilidade óbvia: trabalho para o SQL Sentry .

Os maiores problemas que temos são:

1. Como o @JNK diz, o SQL Server ofusca o uso de uma UDF e faz coisas terríveis com elas de qualquer maneira (como sempre estima uma linha). Quando você gera um plano real no SSMS, também não vê seu uso. Estamos sujeitos às mesmas limitações, pois só podemos fornecer as informações sobre um plano que o SQL Server nos fornece.
2. Contamos com fontes diferentes para métricas de tempo de execução ao gerar um plano real. Infelizmente, o XML do plano não inclui chamadas de função e o SQL Server não revela a E / S incorrida por uma função ao usá- SET STATISTICS IO ON;las (é assim que preenchemos nossa Table I/Oguia).

Considere a seguinte exibição e função em relação ao AdventureWorks2012. Esta é apenas uma tentativa boba de retornar uma linha aleatória da tabela de detalhes, dada uma linha aleatória da tabela de cabeçalho - principalmente para garantir que sempre geremos o máximo de E / S possível.

CREATE VIEW dbo.myview 
WITH SCHEMABINDING
AS
  SELECT TOP (100000) rowguid, SalesOrderID, n = NEWID() 
    FROM Sales.SalesOrderDetail ORDER BY NEWID();
GO

CREATE FUNCTION dbo.whatever(@SalesOrderID INT)
RETURNS UNIQUEIDENTIFIER
WITH SCHEMABINDING
AS
BEGIN
  RETURN 
  (
    SELECT TOP (1) rowguid FROM dbo.myview 
     WHERE SalesOrderID = @SalesOrderID ORDER BY n
  );
END
GO

O que o Management Studio faz (ou não) diz a você

Faça a seguinte consulta no SSMS:

SET STATISTICS IO ON;

  SELECT TOP (5) SalesOrderID, dbo.whatever(SalesOrderID) 
    FROM Sales.SalesOrderHeader ORDER BY NEWID();

SET STATISTICS IO OFF;

Ao estimar um plano, você obtém um plano para a consulta e um único plano para a função (não 5, como seria de esperar):

Você não obtém nenhum dado de E / S, obviamente, pois a consulta não foi realmente executada. Agora, gere um plano real. Você obtém as 5 linhas esperadas na grade de resultados, o plano a seguir (que não faz absolutamente nenhuma menção visível ao UDF, exceto no XML, você pode encontrá-lo como parte do texto da consulta e como parte do Operador Scalar):

E a seguinte STATISTICS IOsaída (que não faz absolutamente nenhuma menção Sales.SalesOrderDetail, mesmo sabendo que ela teve que ler nessa tabela):

Tabela 'SalesOrderHeader'. Contagem de varredura 1, leituras lógicas 57, leituras físicas 0, leituras de read-ahead 0, leituras lógicas de lob 0, leituras físicas de lob 0, leituras físicas de lob 0, leituras de read-ahead de lob 0.

O que o Plan Explorer diz para você

Quando geramos um plano estimado para a mesma consulta, sabemos o mesmo que SSMS. No entanto, mostramos as coisas de uma maneira um pouco mais intuitiva. Por exemplo, o plano estimado para a consulta externa mostra como a saída da função é combinada com a saída da consulta e fica imediatamente claro - dentro de um único diagrama de plano - que há E / S nas duas tabelas :

Também mostramos o plano da função por si só , o qual incluo apenas para completar:

Agora, vamos dar uma olhada em um plano real, que é milhares de vezes mais útil. A desvantagem aqui é que, novamente, temos apenas as informações que o SQL Server decide mostrar, para que possamos expor apenas os diagramas de plano gráfico que o SQL Server nos fornece. Não é uma situação em que decidimos não mostrar algo útil; na verdade, não sabemos nada sobre isso com base no XML do plano que é fornecido a nós. Nesse caso, é como no SSMS, vemos apenas o plano da consulta externa e é como se a função não estivesse sendo chamada :

Nossa guia Table I / O também depende da saída deSTATISTICS IO , que também ignora qualquer atividade executada na chamada de função:

No entanto, temos toda a pilha de chamadas para você. Ocasionalmente, ouvi pessoas perguntando: "Pffft, quando é que vou precisar da pilha de chamadas?" Podemos decompor o tempo gasto, a CPU usada e o número de leituras (e, para TVFs, número de linhas produzidas) para cada chamada de função :

Infelizmente, não temos a capacidade de correlacionar isso de quais tabelas as E / S são originárias (novamente, porque o SQL Server não nos fornece essas informações) e não está rotulado com o nome UDF (porque é capturada como uma instrução ad hoc, não a própria chamada de função). Mas o que ele permite que você veja, que o Management Studio não, é o cão que sua UDF está sendo. Você ainda precisa juntar alguns pontos, mas há menos pontos e eles estão mais próximos.

Sobre o Profiler

Por fim, recomendo fortemente ficar longe do Profiler, a menos que seja para configurar um rastreamento do lado do servidor que você executará fora do escopo de qualquer ferramenta de interface do usuário. O uso do Profiler em um sistema de produção quase certamente causará mais problemas do que jamais será resolvido . Se você deseja obter essas informações, use um rastreamento do lado do servidor ou eventos estendidos e certifique-se de filtrar com muita sabedoria. Mesmo sem o criador de perfil, um rastreio pode afetar seu servidor, e recuperar planos de show através de eventos estendidos também não é a coisa mais eficiente do mundo .