Cuando compilas un stored procedure, debe usar las densidades en lugar de el
histograma de valores de la primera columna de los indices o las
estadisticas porque trata de general el mejor plan independiente del valor.

Cuando compila el plan de ejecucion de un T-SQL que no es un exec puede
optimizar para algun valor concreto y por lo tanto elige el mejor plan
posible.


Agrega al EXEC "WITH RECOMPILE" o al CREATE PROCEDURE

Lo que explique de las fechas se aplica a todos los tipos de datos.
Simepre debe quedar

Columna OPERADOR <valor>

En poco tiempo vamos a dar un seminario sobre Performance en SQL entre otras
cosas.


Saludos




On 4/8/07, Diego Jancic <[EMAIL PROTECTED]> wrote:

 Hola,

Gracias por lo de las fechas, pero creo que sobre las fechas no hay
indices en las tablas. Porque en realidad se realiza filtros por varios
campos, no se si tiene alguna ventaja usar el dateadd si no tiene indices o
si deberiamos crear los indices sobre muchos campos…

Me seria util algun link que explique que hay que tomar en cuenta para
decidir si poner o no un indice, porque imagino que no poner ningun indice
esta mal y poner indice en todos los campos tambien esta mal…



En cuanto a los del SP que es el tema principal, el problema es lo que
dijiste: *Cuando se ejecuta el SP es mas lento que cuando se ejecuta la
consulta directamente (exista o no un trace)*.

Pero no entendi la diferencia entre compilar algo usando *"la alternativa
menos mala*" o usando el *"criterio de la mejor alternativa"*





Gracias,

Diego


 ------------------------------

*From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Jose
Mariano Alvarez
*Sent:* Sábado, 07 de Abril de 2007 20:02
*To:* Diego Jancic
*Subject:* [dbms] Performance entre SP y Consulta directa



Unos cuantos detalles.



No me queda claro si el problema es cunado prendes el trace o cuando
ejecutas el SP



Si el problema es el segundo o sea cunado ejecutas el SP es mas lento,
creo que el problema se debe a un fecomeno clasico de los SP ya que se
compilan tomando el cuenta la alternativa menos mala y cuando usas
T-SQL embebido se compilan siempre (eso es un costo adicional de CPU) usando
el critero de la mejor alternativa.



Algo mas importante y que quiza mejore drasticamente algunas de tus
consultas si tienes los indices adecuados.



Nunca escribas una condicion asi

AND DATEDIFF(day, b.fecha_desde, getdate()) < 30

Esto NUNCA va a usar un indice mediante un SEEK y va a afectar al motor

DEBES SIEMPRE escribirla de esta forma si quieres que use un indice

b.fecha_desde < DATEADD(day, -30, getdate())



Saludos



-
--------------------------------
Atte.
Ing. Jose Mariano Alvarez




--
--------------------------------
Atte.
Ing. Jose Mariano Alvarez

Responder a