Duda sobre las lecturas de una consulta

Victor,

Esto se debe a una facilidad de SQL Server conocida como "parameter
sniffing" (no me se la traduccion al español) y tiene que ver con que SQL
Server crea un plan de ejecucion para el procedimiento basado en valores
tipicos (Valores por default declarados o valores usados en la primera
ejecucion del sp). Cuando se vuelve a ejecutar el sp con valores no tipicos,
entonces el plan no sera el optimo y por enede habra una degradacion en el
rendimiento. Para un mejor analisis de tu caso, postea el codigo completo de
tu procedimineto.

Entre las posibles soluciones tenemos:

- Actualiza las estadisticas (sp_updatestats) y marca el procedimiento para
que se recompile (recompile) y pasar los valores con los que estas probando
el problema

- Declarar variables locales dentro del sp, asignarle los parametros de
entrada y usar las variables en la sentencia select.

- Correr la sentencia select en otro contexto que requiera la creacion de un
nuevo plan de ejecucion. Este es el caso de usar sp_executesql o exec(...)


Aca te paso un link donde se habla sobre el tema.

Parameter sniffing
http://groups-beta.google.com/group...amp;rnum=1


AMB



AMB

"Víctor" wrote:

Hola.

Tengo la siguiente consulta dentro de un Stored Procedure:

SELECT DISTINCT grup_codi, grup_nombre, grup_fechsa, grup_horasa,
bar_nombre
FROM ic_grupoviaje
INNER JOIN ic_viagrup ON grup_codi = vgr_codgrup
INNER JOIN ic_viaje ON via_codi = vgr_codvia
INNER JOIN ic_barco ON via_codbar = bar_codi
WHERE (via_codbar = @barco) AND (bar_tipo = 0)
AND (grup_codlin = @linea ) AND (grup_fechsa BETWEEN @desde AND @hasta)

Resulta que si ejecuto el Stored Procedure cambiando los parámetros por
valores, el Analizador de Trazas me muestra que se realizan unas 40
lecturas. Pero si lo ejecuto pasándole parámetros, realiza unas 90000
lecturas.

¿Por qué?

Entendido.

Muchas gracias por la respuesta.

"Alejandro Mesa" escribió en el
mensaje news:

Victor,

Esto se debe a una facilidad de SQL Server conocida como "parameter
sniffing" (no me se la traduccion al español) y tiene que ver con que SQL
Server crea un plan de ejecucion para el procedimiento basado en valores
tipicos (Valores por default declarados o valores usados en la primera
ejecucion del sp). Cuando se vuelve a ejecutar el sp con valores no

tipicos,

entonces el plan no sera el optimo y por enede habra una degradacion en el
rendimiento. Para un mejor analisis de tu caso, postea el codigo completo

de

tu procedimineto.

Entre las posibles soluciones tenemos:

- Actualiza las estadisticas (sp_updatestats) y marca el procedimiento

para

que se recompile (recompile) y pasar los valores con los que estas

probando

el problema

- Declarar variables locales dentro del sp, asignarle los parametros de
entrada y usar las variables en la sentencia select.

- Correr la sentencia select en otro contexto que requiera la creacion de

un

nuevo plan de ejecucion. Este es el caso de usar sp_executesql o exec(...)


Aca te paso un link donde se habla sobre el tema.

Parameter sniffing

http://groups-beta.google.com/group...amp;rnum=1

AMB



AMB

"Víctor" wrote:

> Hola.
>
> Tengo la siguiente consulta dentro de un Stored Procedure:
>
> SELECT DISTINCT grup_codi, grup_nombre, grup_fechsa, grup_horasa,
> bar_nombre
> FROM ic_grupoviaje
> INNER JOIN ic_viagrup ON grup_codi = vgr_codgrup
> INNER JOIN ic_viaje ON via_codi = vgr_codvia
> INNER JOIN ic_barco ON via_codbar = bar_codi
> WHERE (via_codbar = @barco) AND (bar_tipo = 0)
> AND (grup_codlin = @linea ) AND (grup_fechsa BETWEEN @desde AND

@hasta)

>
> Resulta que si ejecuto el Stored Procedure cambiando los parámetros por
> valores, el Analizador de Trazas me muestra que se realizan unas 40
> lecturas. Pero si lo ejecuto pasándole parámetros, realiza unas 90000
> lecturas.
>
> ¿Por qué?
>
>
>