Ok, mirá, en principio podría decir que el tema estaría solucionado en cuanto al resultado esperado, pero sigo tanto o más desconcertado que antes.
Lo que hice se parece más a un ritual de magia que a un procedimiento con una lógica técnica ;( Tomé el store procedure con sus 11 UNIONS y los comentarié todos menos el primero. Fuí ejecutándo alternativamente la consulta desde la aplicación, descomentando cada uno de los grupos, esperando ver cuál de ellos iba a producir el resultado con lentitud; pero (sorpresivamente) al descomentariar todos el procedure ahora ejecuta en un tiempo normal y aceptable. ;-( Para evitar que no hayan habido temas de cache, probé cambiar el conjunto de parámetros, pero no puedo asegurar que no vuelva a fallar como antes ya que sigo sin controlar la causa del problema. Tomé los parámetros (sets) del profiler con las conexiones existentes: -- mi conexion con mgmt studio set quoted_identifier on DIFIERE set arithabort on xxxxxxxxxxxxx set numeric_roundabort off set ansi_warnings on set ansi_padding on set ansi_nulls on set concat_null_yields_null on set cursor_close_on_commit off set implicit_transactions off set language us_english set dateformat mdy set datefirst 7 set transaction isolation level read committed Con .net -- network protocol: TCP/IP set quoted_identifier on set arithabort off set numeric_roundabort off set ansi_warnings on set ansi_padding on set ansi_nulls on set concat_null_yields_null on set cursor_close_on_commit off set implicit_transactions off set language us_english set dateformat mdy set datefirst 7 set transaction isolation level read committed Como se observa ambas parecen ser idénticas salvo el arithabort, que hasta donde sé, no debería interferir en los planes de ejecución. Así que sigo adelante hasta que vuelva a fallar... -----Original Message----- From: "Pablo A. Allois" <[email protected]> To: "Daniel Aisenberg" <[email protected]> Date: Thu, 19 Feb 2009 13:11:29 -0200 Subject: [dbms] RE: [dbms] Re: [dbms] [vbnet] Re: [vbnet] la consulta es más lenta desde la aplicación? Con el profiler, cuando se loguea la existingconnection te muestra todos los sets. Hace poco me paso algo similar, y Mariano me dio la misma respuesta. Me paso lo mismo con un SP … como para que la aplicacion siga funcionando hasta encontrar el error … cree el SP WITH RECOMPILE … aclaro que no lo recomiendo para que lo dejes … solamente como chanchada temporal. Si queres tener mas info … si la situacion te lo permite generate un profiler que guarde los planes de ejecucion .. ahi podes llegar a ahondar mas en el problema. Saludos! De: [email protected] [mailto:[email protected]] En nombre de [email protected] Enviado el: Jueves, 19 de Febrero de 2009 12:49 p.m. Para: [email protected] Asunto: [dbms] Re: [dbms] [vbnet] Re: [vbnet] la consulta es más lenta desde la aplicación Cómo sé qué proveedor usa? Uso un framework con una capa de acceso a datos, que usa sqlclient, sqlconnection, etc. Tampoco sé cómo ver todos los "sets" con que se conecta la aplicación. Los veo en el profiler? Gracias -----Original Message----- From: Jose Mariano Alvarez <[email protected]> To: "Daniel Aisenberg" <[email protected]> Date: Thu, 19 Feb 2009 12:30:26 -0200 Subject: [dbms] Re: [dbms] [vbnet] Re: [vbnet] la consulta es más lenta desde la aplicación La diferencia es que usa planes diferentes. Se puede ver claramente en los READS. Asegurate de aplicar los SET de la conexion de manera identica. Que proveedor estas usando? -- -------------------------------- Ing. José Mariano Alvarez SQL Total Consulting Bogota 3631 P3B 1407 Buenos Aires-Argentina Movil: (011)-15-4184-7541 Desde el exterior: (+54-911)-4184-7541 [email protected] 2009/2/19 [email protected] < [email protected]> Mariano, abajo resumo los datos del sql profiler para ambas ejecuciones, iguales parámetros y servidor. CPU Reads Duration Mgm.Studio 469 27332 480 Aplic. 413442 258713577 413738 Lucio, probé cambiarle la referencia al servidor en el web.config, pero obtengo el mismo resultado; el servidor tiene seguridad mixta, la aplicación se conecta con un usuario de Sql. De todos modos, en contra de tu hipótesis, pude ver que la aplic, para la mayoría de otras consultas, funciona bien, incluso con esta misma consulta modificada o simplificada funciona bien. Se trata de una consulta que tiene que armar una cuenta conrriente de proveedor para lo cual hace unos 11 union (union all) de conjuntos; pude ver que comentariando ciertos conjuntos, la consulta responde bien desd ado.net también, con lo cual tendría la solución bastante focalizada. Lo que me confunde es porqué de la diferencia de comportamiento desde ado.net y desde sql mgm, dado que la mayoría de las veces , uno asume que la performance de una consulta son iguales o similares y ejecuta las pruebas asumiendo eso. Lo único que se me ocurre pueda estar pasando, es algún issue relacionado con bloqueos que ocurran desde ado.net dado el contexto con que se ejecutan las consultas. Gracias
