¿Por qué hay diferencias de rendimiento cuando se llama a una función SQL desde la aplicación .Net cuando se hace la misma llamada en Management Studio

Question

Estamos teniendo un problema en nuestros entornos de prueba y desarrollo con una función que funciona muy lentamente cuando se llama desde una aplicación .Net. Cuando llamamos a esta función directamente desde el estudio de gestión, funciona bien.

Aquí están las diferencias cuando se perfilan: de la aplicación:
CPU: 906
Lecturas: 61853
escribe: 0
Duración: 926

De SSMS:
CPU: 15
Lecturas: 11243
Escribe: 0
Duración: 31

Ahora hemos determinado que cuando volvamos a compilar la función, el rendimiento vuelve a ser lo que esperamos y el perfil de rendimiento cuando se ejecuta desde la aplicación coincide con el de lo que obtenemos cuando lo ejecutamos desde SSMS. Empezará a ralentizarse de nuevo a lo que parecen intervalos aleatorios.

No hemos visto esto en prod, pero pueden ser en parte porque todo se recompila allí semanalmente.

Entonces, ¿qué podría causar este tipo de comportamiento?

Editar -
Finalmente fueron capaces de hacer frente a este y la reestructuración de las varables para hacer frente a la inhalación de parámetro parece haber hecho el truco ... un fragmento de lo que hicimos aquí: Gracias por su ayuda.

 -- create set of local variables for input parameters - this is to help performance - vis a vis "parameter sniffing" 
    declare @dtDate_Local     datetime 
      ,@vcPriceType_Local    varchar(10) 
      ,@iTradingStrategyID_Local  int 
      ,@iAccountID_Local    int 
      ,@vcSymbol_Local    varchar(10) 
      ,@vcTradeSymbol_Local   varchar(10) 
      ,@iDerivativeSymbolID_Local  int 
      ,@bExcludeZeroPriceTrades_Local bit 

    declare @dtMaxAggregatedDate  smalldatetime 
      ,@iSymbolID    int 
      ,@iDerivativePriceTypeID int 

    select @dtDate_Local     = @dtDate 
      ,@vcPriceType_Local    = @vcPriceType 
      ,@iTradingStrategyID_Local  = @iTradingStrategyID 
      ,@iAccountID_Local    = @iAccountID 
      ,@vcSymbol_Local    = @vcSymbol 
      ,@vcTradeSymbol_Local   = @vcTradeSymbol 
      ,@iDerivativeSymbolID_Local  = @iDerivativeSymbolID 
      ,@bExcludeZeroPriceTrades_Local = @bExcludeZeroPriceTrades 

Answer 1

Esto generalmente se debe a que está obteniendo un plan de ejecución diferente en su conexión SSMS. A menudo está relacionado con problemas de olfateo de parámetros cuando el plan se genera con un valor específico que es subóptimo para otros valores de los parámetros. Esto también explica por qué la recompilación resolvería el problema. Este hilo parece tener una buena explicación Parameter Sniffing (or Spoofing) in SQL Server

Answer 2

Tuve un problema similar con los procedimientos almacenados, y para mí resultó ser 'parámetro sniffing'. Busque eso y vea si resuelve su problema, para mí fue una aceleración dramática una vez que lo arreglé.

En mi caso, lo arreglé declarando una variable local para cada parámetro que se pasó, y luego asigné la variable local a ese valor de parámetro, y el resto del proceso usó las variables locales para procesar ... por la razón que sea, esto derrotó al parámetro sniffing.

Answer 3

Una posible causa son las estadísticas desactualizadas y/o la detección de parámetros que causa que un plan de consulta en caché sea reutilizado y no sea óptimo.

SSMS emite declaraciones previas que usted no ve, que hacen que la consulta enviada sea compilada cada vez, eliminando así la posibilidad de utilizar un plan en caché incorrecto.

Esto actualizará todas las estadísticas y refrescar vistas y procedimientos almacenados (pero tenga cuidado con que se ejecuta en una máquina de producción):

EXEC sp_updatestats 

EXEC sp_refreshview 

EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''