Optimizacion De Rendimiento

[juanlito]

Buenas, se que quizas no pueda pedir mas, ya que las tablas tienen bastantes registros unos 200000 cada una, pero este ultimo SP del que he hablado, me tarda 15 minutos en mostrarme datos, se que antes era mas de 2 horas, y que he Optimizado mucho, pero aun asi para que el cliente decida, ahora veo datos, y necesite 15 minutos pues..... ya saben se aburre de esperar.

Podria hacerlo de alguna otra forma que mejorase mas aun, las pruebas ya las estoy haciendo con la BD en otro equipo remoto, para que salga como el resultado final.

Ganaria velocidad si reduzco el numero de columnas de las tablas, en realidad las tablas tienen muchos campos que no uso, con menos campos en las tablas seria mas rapido o eso influye poco?

Gracias de antemano.

[[fjcg02]]

Hola Juanlito:

yo intentaría varias cosas:
- hacer todo en una sola query, es decir, con 'CASE' intentar hacer en una sola select lo que haces en el procedimiento almacenado. Si lo consigues, podrías dejarlo en una vista en lugar de un procedimiento almacenado.
- Revisar que los campos por los que preguntas, cruzas y filtras tienen indices. Si no tienen, añadirlos y ver si afecta al rendimiento cuando se hacen las inserciones, ya que al motor le costará algo más.
- Intentar cambiar de la condición ((PLAT.DESTINO) Like :CALLED) el 'like' y poner '=' ( si puedes ).

Ya nos contarás. Si tienes alguna dificultad, ponnos la bbdd con información para que podamos probar.

Saludos

[juanlito]

Ante todo disculparme por el retraso en responder, me han surgido otras cosas que me tienen muy ocupado y no he podido avanzar con mi problema, ni probar cosas nuevas.

Muchas gracias por tus sugerencias, en cuanto tenga un rato las probare como es debido.

Lo de los indices, deberia de estar indexado pero lo comprobare, como los datos vienen importados de access quizas algunos indices no sean los mejores, vi que se habian creado indices y por eso no les presté la debida atencion.

Con respecto a hacer una sola query con CASE, realmente no se como hacerlo, si hubiera sabido ten por seguro que no tendria un codigo tan complejo, pero viendo que me lo das como opcion( creia que no se podia hacer), me documentare de como podria hacer que mi codigo se redujese a un query.

Sobre el ultimo punto, hice una prueba rapida, y cambiando el 'like' por '=' la verdad es que no note mejora, no calcule exactamente pero estara en el mismo tiempo.

Un saludo y seguire informando de los avances cuando pueda ir probando.

Muchas Gracias

[juanlito]

Buenas Tardes,

consegui hacer todo y que mi aplicacion fuese rapida, pero pensando en el futuro he observado que si uso

Código SQL [-]
 
SELECTcount( PLAT.LINEA) FROM PLAT WHERE ((PLAT.LINEA) = :CALLING) 
   INTO :VECES ;
   if (:VECES = 0)  then
   begin
    EXIT;
    suspend;

El procedimiento cada vez que la tabla vaya creciendo se ira ralentizando porque tendra que finalizar la consulta y a mi con que encuentre un campo me vale.

He estado consultando y he encontrado que con el FIRST podria hacer lo que prentendo, en cuanto encuentre un campo parar la consulta porque ya es distinto de 0 y con eso me sirve, el principal problema es que he puesto el siguiente codigo

Código SQL [-]
  SELECT FIRST 1 ( PLAT.LINEA) FROM PLAT WHERE ((PLAT.LINEA) = :CALLING)
  INTO :VECE;
   if (:VECE IS NULL ) then

Y no me funciona, he probado poniendo order by al final, comparando en el IF en vez de NULL si cadena vacia '' pero no consigo que me funcione como quiero, solo funciona cuando uso el count, pero me gustaria no tener que hacer el select entero y poder quedarme tranquilo de que aunque mis tablas crezcan ( que creceran bastante) no se va a empezar a ralentizar de manera grande.

Pruebo directamente en un view de firebird.

Muchas gracias y si llevo tiempo con el hilo un poco parado es porque siempre procuro solucionar yo los problemas.

Un saludo

[[fjcg02]]

Hola,
PLAT.LINEA es del mismo tipo que VECE ?
VECE será entero, que es el mismo tipo de dato que devuelve COUNT. Por ahí podría darse un conflicto...

Prueba y nos dices

Saludos

[juanlito]

Ya pense en esa opcion,

vece es del mismo tipo que plat.linea VARCHAR(20), por eso no lleva la 's' que llevaba en el codigo del count, para diferenciarlo fue una de las pruebas que hice.

Pero gracias, todas las pruebas son validas, probe con IS NOT NULL, o con cadena vacia '' o con ' ' pero nada siendo un VARCHAR.

[[fjcg02]]

Hola,
he estado echando un vistazo al problema, y creo que lo que te ocurre es que la tabla GUAN tiene muchos registros.

Puedo equivocarme, pero creo que deberías limigtar el nº de registros de la consulta a la tabla GUAN, para que el retardo no se excesivo. Quiero decir, que si estás mirando llamadas, siempre serán las limitadas entre unas horas, minutos, o incluso un día, pero seguramente no se preguntará por todas las llamadas de la tabla.

Respecto al problema de la limitación de registros, en principio la consulta con FIRST es correcta. Has probado a ejecutarla fuera del SP ? Creo que tu idea es correcta respecto a cómo agilizar las consultas, pero a veces es lo que hay. Lo que no sé es si es posible que añadas un campo a tus tablas que se calcule en base al timestamp, para que puedas ponerle un indice y poder cruzar las tablas por él, que sería lo más óptimo. Ten en cuenta que preguntas por un rango de +-2 horas, que es lo que te está rompiendo los tiempos de respuesta.

Un saludo