13 respuestas en este tema

[razadi]

Buen día amigos, me preguntan si hay forma de saber que proceso, tabla u "algo" esta siendo más usada en una base de datos Firebird, ya que de momentos su base de datos se alenta demasiado.

Hay alguna herramienta que nos permita ver esas estadísticas mientras la base de datos está siendo usada en producción?

saludos y gracias de antemano?

[Caral]

Hola
Que yo sepa la base de datos no se alenta lo que hace es guardar los datos.
Lo que si se alenta es la busqueda o la insercion de datos y esto no es culpa de la BD es culpa de la manera en como se hacen estas ya sea con sql u otro.
Saludos

[razadi]

Hola
Que yo sepa la base de datos no se alenta lo que hace es guardar los datos.
Lo que si se alenta es la busqueda o la insercion de datos y esto no es culpa de la BD es culpa de la manera en como se hacen estas ya sea con sql u otro.
Saludos

Gracias por responder, si definitivamente es así (también lo sé), pero precisamente habrá algo que pueda medir el tiempo de realizar una consulta una inserción o un delete o el llamado por un trigger desde la propia base de datos, porque en delphi hay unos componentes (o había) que monitoreaba precisamente esas operaciones, pero la aplicación que consume esa base de datos la desarrollaron otros y pues me preguntan a mi, ahora ya les comente que probablemente sea su conexión a la base (red o plataforma) pero ellos perjuran que eso no es.

[poliburro]

entonces buscas algo como sp_who de sql server. Espero que alguien más docto en el tema nos pueda ayudar.

[razadi]

Algo similar amigo, aunque con el tiempo de cada transacción, digo no sé realmente si haya algo parecido para firebird, o alguna herramienta que se aproxime.

gracias

[Caral]

Hola
Hace tiempo hice un tutorial que media la velocidad de transacciones en diferentes BD.
Aqui esta revisalo tal vez te sirva de ejemplo.
http://www.delphiacc...bird-velocidad-)-novatos/
saludos

[Delphius]

Firebird viene con un tool que permite recabar ciertas "estadísticas" para diagnosticar que tan "saludable" está la base de datos. Se llama gstat, recomiendo que leas su documentación.

También puedes probar productos de terceros, como los de IB Surgeon. Ofrecen unas buenas aplicaciones dedicadas al mantenimiento, recuperación de datos, y de análisis de permofance. Creo que lo que pides se puede hacer con FBScanner e/o IBAnalist.

Saludos,

[razadi]

Gracias Caral lo voy a revisar y lo checo mi estimado Delphius, 

[Delphius]

Yo recuerdo haber probado alguna vez uno de los productos de IB Surgeon pero no recuerdo cual. No le di mucha mirada porque no andaba con tiempos pero a simple vista parecía ofrecer muchas cosas. Lo que si es que no me resultó tan fácil o digerible, tuve mis dificultades... propias de novato cuando toca algo que no ha usado, pero nada grave. Recomiendo que antes de usarlo, leas su documentación.

Se que otros compañeros han usado con éxitos las herramientas de IBSurgeon. Puede que si alguno saca tiempo y ve este hilo pueda ofrecerte un mejor panorama. Yo admito que en el tema de las estadísticas, el uso de gstat lo tengo un tanto verde. No he practicado suficiente este tool.

Saludos,

[Sergio]

Aparte de las herramientas que se mencionan, centrate lo primero en ver el tiempo de ejecucion de las SQLs que uses en tu aplicacion, si alguna de ellas tarda mas de la cuenta, mira el "plan" que genera, suelen haber formas de acelerar las consultas mas lentas x100 si sabes como.

Lo normal es que en el plan veas la palabra "natural" eso te indica que le faltaria un indice para poder acelerar esa consulta.

Lo siguiente más habitual es que al cambiar de sitio las tablas del "from" y las de los "join" de forma que la mas usada, la tabla principal digamos, este en el from ayuda mucho.

Por ejemplo:

"select * from tabla1 t1 left join tabla2 t2 on t2.id=t1.id where t2.fecha between 10.12.2014 and 15.12.2014"

Como veis, se filtra por una fecha de t2 pero en el from aparece t1. Si lo cambias ahorras mucho tiempo y el servidor se ahorra mucho trabajo:

"select * from tabla2 t2 left join tabla1 t1 on t2.id=t1.id where t2.fecha between 10.12.2014 and 15.12.2014"

Otra cosa: Nunca uses transacciones que modifiquen datos de larga duracion. Una transaccion que se inicia al entrar al programa, cambia un dato, y no hace commit hasta salir del programa afecta al rendimiento de FireBird, los cambios se hacen lo más rapido posible y se les hace un commit, todo de un golpe.

Con estos consejos conseguimos rebajar los tiempos de las consultas de forma a veces espectacular, y nunca hemos necesitado usar herramientas de terceros.

[razadi]

Gracias Delphius, estoy seguro que si y por lo pronto estoy revisando la página, Sergio, muchas gracias por los consejos, seguro los tomare en cuenta, aunque en esta ocasión no una aplicación mía por lo que no podré revisar sus querys.

[Sergio]

Gracias Delphius, estoy seguro que si y por lo pronto estoy revisando la página, Sergio, muchas gracias por los consejos, seguro los tomare en cuenta, aunque en esta ocasión no una aplicación mía por lo que no podré revisar sus querys.

..pero SI puedes añadir indices a la base de datos por tu cuenta, y FireBird los usara automaticamente!

[razadi]

..pero SI puedes añadir indices a la base de datos por tu cuenta, y FireBird los usara automaticamente!

mmm no lo había pensado, gracias Sergio veré de esa manera, gracias!

[Delphius]

..pero SI puedes añadir indices a la base de datos por tu cuenta, y FireBird los usara automaticamente!

Depende... Firebird cuenta con un indicador o métrica de uso por cada índice. Dependiendo de eso evalúa si emplea un índice, otro, o ninguno.

Saludos,