10 respuestas en este tema

[TiammatMX]

Buena tarde, jóvenes.

Tengo un pequeño detallín con el resultado de un Stored Procedure, el cual tiene un tiempo de procesamiento de más de 15 minutos, un mundo de tiempo que el venerable Delphi 6 que estoy usando para desarrollar la aplicación con un TADOQuery que recoge ése resultado no alcanza a procesar; al grado que inicia el procesamiento de ése SP y la aplicación Delphi "cierra" la conexión, tira el servicio y no muestra el resultado en un reporte, que es la finalidad de ésta aplicación.

¿Alguna idea que me permita ejecutar el Stored Procedure HASTA QUE TERMINE y arroje el resultado deseado al reporte?

[fredycc]

Q tal TiammatMX, creo el detalle debe ser el timeout de la conexión, que también en los componentes ADO de Delphi debe ser 0 para esperar hasta que la ejecución del SP sea completada y evitar se desconecte, ahora si tira el servicio me imagino que te refieres al de base de datos, entonces dependiendo del motor de bd que utilices ejecuta tu consulta directamente, yo uso IBExpert para firebird o el Management del SQL Server para MS SQL Server para verificar el performace de mis consultas e identificar los cuellos de botella, en Firebird mi problema era con las UDF que tiraban el servicio porque con controlaba ciertos valores de entrada y salida.

Saludos

[Rolphy Reyes]

Saludos.

¿Es necesario que dure todo ese tiempo en ejecución?
¿Es posible disminuir el tiempo de procesamiento?

[Marc]

Hola.

Un tiempo de ejecución tan alto normalmente suele implicar que hay consultas dentro del procedimiento almacenado que no están bien optimizadas (mediante índices).

Cuando en un procedimiento almacenado hay una subconsulta mal optimizada, a copia de repetirse varios cientos de veces en el bucle principal, puede provocar estos tiempos de varios minutos de ejecución.

En cualquier caso, la versión profesional de IB-Expert (y de otros gestores comerciales de Firebird) lleva un depurador de procedimientos almacenados, con el que ejecutar el procedimiento línea a línea, y ver donde está el problema.

Instala al menos su versión de evaluación, para poder probar esta característica.

Otra buena idea es ejecutar independientemente cada consulta integrada en el procedimiento almacenado, para ver su plan de ejecución y asegurarte de que tiene los índices adecuados para ejecutarse de forma óptima.

Saludos.

[Marc]

Vaya, no sé porqué di por supuesto que la base de datos es Firebird. Ahora veo que es SQL Server.

En cualquier caso, mi consejo sería el mismo. Prueba a depurar tu SP con el depurador de procedimientos almacenados que integra SQL Server, y revisa el plan de ejecución de las consultas integradas en dicho procedimiento.

NOTA: Muchas veces también habrá que revisar los triggers de las tablas modificadas por el procedimiento almacenado. Puesto que si un trigger está mal optimizado, normalmente no será apreciable al modificar solo un registro, pero en cambio al intentar modificar muchos registros, el retraso se hará enorme. La solución es la misma que en el procedimiento almacenado, hay que revisar el plan de ejecución de las consultas implicadas en el trigger, para asegurarnos de que estén optimizadas correctamente con un índice adecuado.

Saludos.

[TiammatMX]

¿Es necesario que dure todo ese tiempo en ejecución?

Sí, es un reporte importantísimo.

¿Es posible disminuir el tiempo de procesamiento?

No, el DBA ya hizo todo lo humana y técnicamente posible y no pudo bajarle NADA al tiempo.

...creo el detalle debe ser el timeout de la conexión, que también en los componentes ADO de Delphi debe ser 0 para esperar hasta que la ejecución del SP sea completada y evitar se desconecte...

Y así está definido, pero simplemente mientras hace lo suyo, no permite más procesos.

Hola.

Un tiempo de ejecución tan alto normalmente suele implicar que hay consultas dentro del procedimiento almacenado que no están bien optimizadas (mediante índices).

Cuando en un procedimiento almacenado hay una subconsulta mal optimizada, a copia de repetirse varios cientos de veces en el bucle principal, puede provocar estos tiempos de varios minutos de ejecución.

En cualquier caso, la versión profesional de IB-Expert (y de otros gestores comerciales de Firebird) lleva un depurador de procedimientos almacenados, con el que ejecutar el procedimiento línea a línea, y ver donde está el problema.

Instala al menos su versión de evaluación, para poder probar esta característica.

Otra buena idea es ejecutar independientemente cada consulta integrada en el procedimiento almacenado, para ver su plan de ejecución y asegurarte de que tiene los índices adecuados para ejecutarse de forma óptima.

Saludos.

Independientemente del motor, el DBA ya revisó, modificó, probó, hizo todo lo posible para bajar el tiempo de procesamiento y no se logró hacer nada. El problema lo tengo yo ahora mismo por el punto de que el DBA ya se dió por vencido intentando bajar el tiempo.

[egostar]

Eso pasa en una máquina remota o en la misma máquina donde se localiza la base de datos ?

Estás utilizando transacciones ?

Porque no generas un hilo exclusivo para ese proceso y/o una aplicación "standalone" que no involucre otros procesos que le demanden atención.

O sea, el pedo ya está en tu cancha y a rajarse a su rancho

Saludos

[fredycc]

Mmm interesante asunto, me ha pasado mucho en MS SQL Server, que hay veces en si tu SP principal invoca otros SP's surgen bloqueos entre ellos, si es este tu motor o cualquier otro yo me iría a monitorear los tiempos de ejecución de cada SP o query, analizar los tiempos y si es que no existen bloqueos por otras transacciones como sugiere Marc, usa el SQL Server Profiler, es lo que normalmente hago en SP's inmensos en MS SQL Server en cierres que toman hasta horas en procesarse.

Ahora que si la ejecución del mismo SP directamente en el servidor colapsa tu servidor, mmm TAdoQuery y Delphi estan libres de culpa, jajaja.


Saludos

[egostar]

.....  Ahora que si la ejecución del mismo SP directamente en el servidor colapsa tu servidor, mmm TAdoQuery y Delphi estan libres de culpa, jajaja........

Vaya, no había leído/entendido eso. Pues si, poco se puede hacer con delphi si el problema se presenta directamente en la base de datos.

Saludos.

[TiammatMX]

Eso pasa en una máquina remota o en la misma máquina donde se localiza la base de datos ?

Sucede en CUALQUIER máquina, y ésta aplicación NO corre en el servidor, precisamente para no generarle más carga al procesador.

Estás utilizando transacciones ?

Nope..., el resultado de éste SP es arrojar el resultado en una tabla cursor.

Porque no generas un hilo exclusivo para ese proceso y/o una aplicación "standalone" que no involucre otros procesos que le demanden atención.

Está en un hilo exclusivo. ¿Recuerdas alguna vez hice una consulta sobre hilos? Fue precisamente para éste caso en particular.

O sea, el pedo ya está en tu cancha y a rajarse a su rancho

Ciertamente, es mi perro y yo lo baño... 

Mmm interesante asunto, me ha pasado mucho en MS SQL Server, que hay veces en si tu SP principal invoca otros SP's surgen bloqueos entre ellos, si es este tu motor o cualquier otro yo me iría a monitorear los tiempos de ejecución de cada SP o query, analizar los tiempos y si es que no existen bloqueos por otras transacciones como sugiere Marc, usa el SQL Server Profiler, es lo que normalmente hago en SP's inmensos en MS SQL Server en cierres que toman hasta horas en procesarse...

No hemos probado éste enfoque. Le comentaré al DBA sobre éste detalle y les comento.

[Delphius]

Hola,
Tal vez no sea lo más optimo y LA respuesta que buscas pero... Si es que el SP tiene como función hacer muchos cálculos, subconsultas, y varios procesos intermedios quizá un enfoque de "divide y vencerás" podría ayudar a alivianar.

Primeramente considera la utilización de tablas "resúmen" que almacenen algunos datos pre-calculados que se utilicen en algunas operaciones de SP. Quizá se haga más grande y compleja la base de datos pero estos tipos de tablas con datos calculados ayudan mucho cuando se tienen muchos registros de varias tablas relacionadas... Cuanto más existan más se tarda el server en hacer los cálculos. Si algunos de estos datos se almacenaran en estas tablas resumenes no hace falta tener que estar explotando los miles de registros y de tablas.

En segundo lugar busca proponer una descomposición de dicho SP. ¡Es tan necesario que haga todo ese trabajo en un SP? ¿Porqué no descomponerlo en pedazos más chicos... y que alimenten informes separados? A veces es mejor tener dos o tres informes fáciles de tirar que tener un mega informe que no llega más... Está bien que se aproveche el poder de una máquina para ayudarnos a tomar decisiones, pero que no se abuse... y que el jefecito aprenda a usar la cabeza y unir al vuelo lo que lee de los informes 

Saludos,