Hola de nuevo Una pregunta, según lo que entendi si yo recompilo el SP de nuevo lo va a compilar de nuevo sin usar las estadisticas?
En caso de que al recompilarlo de nuevo use las estadisticas, deberia ejecutar SIEMPRE el SP de esa forma?? Aunque lo dudo porque estaria recompilandolo siempre Entonces: Lo que tendria que hacer es cada algun tiempo recompilar el SP para que use las nuevas estadisticas y normalmente en la aplicacion ejecutarlos sin recomilar? Gracias de nuevo!, Diego _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jose Mariano Alvarez Sent: Domingo, 08 de Abril de 2007 20:03 To: Diego Jancic Subject: [dbms] Performance entre SP y Consulta directa 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
