velocidad en Procedimiento almacenado

[jc.guzman]

Buenas tardes amigos, he elaborado un procedimiento almacenado que elabora la facturacion de usuarios en un sistema de agua potable, las tablas que utiliza son varias, y de una gran cantidad de registros, la mas grande tiene un millon de registros, lo extraño del asunto es que en algunas ocasiones el procedimiento es super veloz (un minuto en ejecutarse) y si lo ejecuto mas tarde sin hacer ningun cambio a la base de datos de ningun tipo(todo igual) ya no tarda un minuto tarda 10 minutos, estas pruebas las llevo a cabo en una computadora sin usuarios conectados. Cuando veo el administrador de tareas se me hace extraño que el proceso FBServer solo este utilizando el 40% o menos del procesador. Alguien me podria decir que es lo que pasa o como configuro el Manejador de base de datos para que haga mas uso del procesador y ejecute mas rapido el proceso. He notado que en algunas ocasiones hace uso del 80 o del 90% de los recursos de procesamiento. Bueno amigos ojala alguno de ustedes me pueda ayudar. gracias.

Pd. Tengo instalado el Firebird 1.5.2
la base de datos es de 1 GB.
La computadora es un pentium 4 a 2.2
con 512 Mb en RAM.

[Fita]

En el archivo IB_Config hay una opcion para lo que deseas hacer.

Nunca lo he hecho, asi que no puedo darte recomendaciones.
Espero te sirva

Saludos

[cahosoft]

hola como estas...
bueno muchas veces en el caso en que estas juega mucho el hardware, lo pimero es tratar de montar el server con tecnolocia scii, que es mucha mas rapida que la IDE....

en el caso de la db... te pregunto las tablas que estan implicadas en la funcion tienen indices... recuerda que estos ayudan en el tiempo de respuestas de la consulta....?

espero ser de ayuda...

[jachguate]

Creo que hay varios puntos a considerar:

• Si tenes activado el hyperthreading y realizas una única conexión, el servidor está limitado al 50% del uso total del procesador (el de un procesador virtual). Habrá que desactivar el hyperthreading.
• Firebird ha demostrado poder mantener el procesador al 100% si se le da suficiente que hacer, incluso con una única conexión. Si el procesador se mantiene mas bajo, es porque tu aplicación no le da suficiente trabajo, probablemente realizas lecturas cortas, te llevas los datos al programa, los manipulas y finalmente haces una escritura corta. Mientras tu aplicación está haciendo cálculos, firebird está esperando por mas cosas que hacer. Una solución típica es transferir carga al servidor (usando stored procedures, por ejemplo), aprovechando que regularmente, en entornos en producción, el hardware del servidor es mucho mas potente y que tenes que pasar menos datos por la red. Otra solución es optimizar tu aplicación para que responda mas rápido, y otra es hacer una aplicación multihilos, donde un hilo se encargue de mantener ocupada a la base de datos y otros cuantos de realizar los cálculos, si estos resultan ser muy complejos.

Espero haber contribuido en algo con estas ideas.

Hasta luego.

[jc.guzman]

Les comento que dentro del procedimiento almacenado he descubierto que cuando se hace un for Select...Do para ejecutar una serie de acciones( Lo cual es mi caso para hacer un proceso de facturación) el uso de operadores Or dentro del For hace lento el procedimiento. Por ejemplo un borrado de datos es mucho mas lento haciendo uso de operadores Or
For Select.........Do Begin
DELETE FROM SALDOS_D
WHERE SDCUENTA=:ICUENTA AND SDMES=:IMES AND SDYEA=:IYEA
AND
((SDCONCEPTO=1) or (SDCONCEPTO=2) or
(SDCONCEPTO=7)or(SDCONCEPTO=8));
End

Si lo realizo de esta manera el proceso increiblemente es mas rapido

For Select.........Do Begin
DELETE FROM SALDOS_D
WHERE SDCUENTA=:ICUENTA AND SDMES=:IMES AND SDYEA=:IYEA
AND (SDCONCEPTO=1);
DELETE FROM SALDOS_D
WHERE SDCUENTA=:ICUENTA AND SDMES=:IMES AND SDYEA=:IYEA
AND (SDCONCEPTO=2);
DELETE FROM SALDOS_D
WHERE SDCUENTA=:ICUENTA AND SDMES=:IMES AND SDYEA=:IYEA
AND (SDCONCEPTO=7);
DELETE FROM SALDOS_D
WHERE SDCUENTA=:ICUENTA AND SDMES=:IMES AND SDYEA=:IYEA
AND (SDCONCEPTO=8);
End

Es decir no hago uso de los opoeradores OR, lo mismo he detectado cuando llevo a cabo sumas o Count, obviamente los indices lo he optimizado, la tabla SALDOS_D tiene 3 indices:
1:SDCUENTA,SDYEA,SDMES,SDCLAVE_PAGO
2:SDCONCEPTO,SDNUMERO_MES
3:SDCUENTA,SDCONCEPTO,SDYEA,SDMES (llave primaria)

Cuando la operacion la lleva a cabo en un for select donde solo lo hace una vez el proceso es igual de rapido pero cuando el for.. select es contiene mas ciclos la direnecia es enorme, esto lo he visto usando el Performace Analizer del IBExpert.

[lbuelvas]

Deberias revisar que indices tiene la tabla saldos_d, es posible que al borrar registros, el motor deba hacer un recorrido natural de la tabla, es decir, recorrer la tabla de comienzo a fin.

El indice podria ser por los campos y en este orden {idcuenta, sdyea, sdmes} por asuntos de selectividad.

Si la tabla tiene muchos registros y estas lanzado la operacion varias veces (for select ...) sera perceptible la demora.

Otra cosa, he observado que cuando se hacen borrados masivos de registros o muchas modificaciones a registros y debido a al tecnologia de multiversiones de registros que maneja Firebird e Interbase, la base de datos se va degradando en rendimiento lo que obliga a hacer backup/restore frecuentes.

Espero te sea de utilidad.