¿SQL Sentry Plan Explorer cuenta las lecturas en UDF?

Tengo una consulta como esta:

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

En SQL Sentry Plan Explorer, noté que tengo que ejecutar Obtener plan estimado en SQL Sentry para que el Plan de consulta incluya el UDF.

Al ejecutar 'Obtener plan real', no parece que las lecturas lógicas y otras métricas incluyan las operaciones que ocurren en el UDF. En casos como este, ¿es la única solución para usar Profiler?

Descargo de responsabilidad obvio: trabajo para SQL Sentry .

Los mayores problemas que tenemos son:

1. Como dice @JNK, SQL Server ofusca el uso de un UDF y hace cosas terribles con ellos de todos modos (como siempre estima una fila). Cuando genera un plan real en SSMS, tampoco ve su uso en absoluto. Estamos sujetos a las mismas limitaciones porque solo podemos proporcionar la información sobre un plan que SQL Server nos proporciona.
2. Confiamos en diferentes fuentes para las métricas de tiempo de ejecución al generar un plan real. Desafortunadamente, el plan XML no incluye llamadas a funciones, y SQL Server no revela la E / S incurrida por una función cuando se usa SET STATISTICS IO ON;(así es como llenamos nuestra Table I/Opestaña).

Considere la siguiente vista y función contra AdventureWorks2012. Esto es solo un intento tonto de devolver una fila aleatoria de la tabla de detalles dada una fila aleatoria de la tabla de encabezado, principalmente para asegurarse de que generamos tanta E / S como sea posible, cada vez.

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

Lo que Management Studio hace (y no dice)

Tome la siguiente consulta en SSMS:

SET STATISTICS IO ON;

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

SET STATISTICS IO OFF;

Cuando estima un plan, obtiene un plan para la consulta y un plan único para la función (no 5, como es de esperar):

Obviamente, no obtiene ningún dato de E / S, ya que la consulta no se ejecutó realmente. Ahora, genera un plan real. Obtiene las 5 filas que esperaba en la cuadrícula de resultados, el siguiente plan (que no hace ninguna mención visible de la UDF, excepto en el XML que puede encontrarlo como parte del texto de consulta y como parte del Operador Escalar):

Y el siguiente STATISTICS IOresultado (que no menciona en absoluto Sales.SalesOrderDetail, a pesar de que sabemos que tuvo que leer de esa tabla):

Tabla 'SalesOrderHeader'. Cuenta de escaneo 1, lecturas lógicas 57, lecturas físicas 0, lecturas de lectura anticipada 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas lob de lectura anticipada 0.

Lo que te dice Plan Explorer

Cuando generamos un plan estimado para la misma consulta, sabemos lo mismo que SSMS. Sin embargo, mostramos las cosas de una manera un poco más intuitiva. Por ejemplo, el plan estimado para la consulta externa muestra cómo se combina el resultado de la función con el resultado de la consulta, y queda claro inmediatamente, dentro de un diagrama de plan único, que hay E / S en ambas tablas :

También mostramos el plan de la función por sí mismo , que solo incluyo para completar:

Ahora, echemos un vistazo a un plan real, que es miles de veces más útil. La desventaja aquí es que, nuevamente, solo tenemos la información que SQL Server decide mostrar, por lo que solo podemos exponer los diagramas de plan gráfico que SQL Server nos brinda. Esta no es una situación en la que hemos decidido no mostrarte algo útil; en realidad no sabemos nada al respecto en función del plan XML que se nos proporciona. En este caso, es como en SSMS, solo vemos el plan de la consulta externa, y es como si la función no se llamara en absoluto :

Nuestra pestaña Tabla I / O también se basa en la salida deSTATISTICS IO , que también ignora cualquiera de las actividades realizadas en la llamada a la función:

Sin embargo, tenemos la pila de llamadas completa para usted. De vez en cuando escuché a la gente preguntar: "Pffft, ¿cuándo necesitaré la pila de llamadas?" De hecho, podemos desglosar el tiempo dedicado, la CPU utilizada y el número de lecturas (y, para TVF, el número de filas producidas) para cada llamada a la función :

Desafortunadamente, no tenemos la capacidad de correlacionar eso con las tablas de las que proviene la E / S (nuevamente, porque SQL Server no nos da esa información), y no está etiquetada con el nombre UDF (porque se captura como una declaración ad hoc, no la función se llama a sí misma). Pero lo que sí le permite ver, que Management Studio no lo hace, es qué perro es su UDF. Todavía tiene que unir algunos puntos, pero hay menos puntos y están más juntos.

Sobre Profiler

Finalmente, recomendaría encarecidamente mantenerse alejado de Profiler, a menos que sea para configurar un rastreo del lado del servidor que vaya a ejecutar fuera del alcance de cualquier herramienta de interfaz de usuario. Usar Profiler contra un sistema de producción seguramente causará más problemas de los que resolverá . Si desea obtener esta información, utilice un seguimiento del lado del servidor o eventos extendidos, y asegúrese de filtrar con mucha prudencia. Incluso sin un generador de perfiles, una traza puede afectar a su servidor, y recuperar planes de presentación a través de eventos extendidos tampoco es lo más eficiente del mundo .