O SentryOne Plan Explorer conta as leituras em UDFs?

Os maiores problemas que temos aqui são:

1. Como diz o @JNK, o SQL Server ofusca o uso de um UDF e faz coisas terríveis com eles de qualquer maneira (como sempre estima uma linha). Quando você gera um plano real no SSMS, também não vê seu uso. O Plan Explorer está sujeito às mesmas limitações porque só pode fornecer as informações sobre um plano fornecido pelo SQL Server.
2. O código depende de fontes diferentes para métricas de tempo de execução ao gerar um plano real. Infelizmente, o plano XML 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;-la (é assim que a Table I/Oguia é preenchida).

Considere a seguinte exibição e função em 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 geramos o máximo de E/S possível, todas as vezes.

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 diz (e não) 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 você pode esperar):

Obviamente, você não obtém nenhum dado de E/S, 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 seguinte plano (que não faz absolutamente nenhuma menção visível ao UDF, exceto no XML que você pode encontrá-lo como parte do texto da consulta e como parte do Operador Escalar):

E a seguinte STATISTICS IOsaída (que não faz absolutamente nenhuma menção a Sales.SalesOrderDetail, embora saibamos que ele teve que ser lido dessa tabela):

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

O que o Plan Explorer diz a você

Quando o PE gera um plano estimado para a mesma consulta, ele sabe o mesmo que o SSMS. No entanto, mostra as coisas de uma forma 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 de ambas as tabelas :

Ele também mostra o plano da função por si só , que estou incluindo apenas para completar:

Agora, vamos dar uma olhada em um plano real, que é milhares de vezes mais útil. A desvantagem aqui é, novamente, que ele só tem as informações que o SQL Server decide mostrar, portanto, só pode expor o(s) diagrama(s) de plano gráfico que o SQL Server fornece. Esta não é uma situação em que alguém decidiu não lhe mostrar algo útil; ele simplesmente não sabe nada sobre isso com base no plano XML fornecido. Nesse caso, é como no SSMS, você só consegue ver o plano da consulta externa, e é como se a função não estivesse sendo chamada :

A 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, o PE obtém toda a pilha de chamadas para você. Ocasionalmente, ouvi as pessoas perguntarem: "Pffft, quando vou precisar da pilha de chamadas?" Bem, você pode detalhar o tempo gasto, a CPU usada e o número de leituras (e, para TVFs, o número de linhas produzidas) para cada chamada de função :

Infelizmente, você não tem a capacidade de correlacionar isso com a(s) tabela(s) de onde vem a E/S (novamente, porque o SQL Server não fornece essas informações) e não é rotulado com o nome UDF (porque é capturado 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 permite, é como seu UDF está sendo um cachorro. 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 para o qual você fará o script e, em seguida, executará fora do escopo de qualquer ferramenta de interface do usuário. Usar o Profiler em um sistema de produção quase certamente causará mais problemas do que jamais resolverá . 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 profiler, um rastreamento pode afetar seu servidor, e recuperar planos de execução por meio de eventos estendidos também não é a coisa mais eficiente do mundo .