FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
|||
|
|||
Hola Casimiro
Cita:
un saludo. |
#22
|
|||
|
|||
Compartenos los metadatos de las tablas importantes de tu base de datos para entender un poco mas la situacion. De acuerdo con Casimiro que tampoco he necesitado en mas o menos los mismos años modificar la configuracón por defecto del motor de base de datos Firebird, el aumento de cache lo que permite es que parte de la base de datos queda en la memoria RAM aumentando la velocidad en la manipulacion y consulta de datos y su uso es para casos muy especiales, tal vez el tuyo.
__________________
Luis Fernando Buelvas T. |
#23
|
||||
|
||||
A lo mejor no es la BD ¿lo has probado en un servidor linux normal y corriente?
|
#24
|
||||
|
||||
Cita:
El porque la 1era vez es lento y luego rapido me parece obvio. Al principio la tabla de destino esta "vacia", luega la llenas, luego al repetir ya esta llena y solo copia los registros faltantes. El filtro de la consulta hace todo rapido. Lo que no entiendo, es porque hay que preocuparse al siguiente dia por esto. Siempre la tabla de destino esta "vacia" al arrancar???
__________________
El malabarista. |
#25
|
|||
|
|||
Hola
Cita:
Tuve un profe en EGB que nunca ponía un 10, decía que siempre hay más caminos y que seguro que hay otro mejor. El producto cartesiano que tanto nos preocupa no es el problema, ese producto, incluso sin condiciones que filtren las tablas, lo resuelve en milisegundos (con fetch all). Por cierto lo probé en un FB2.5.2 64bits en modo superClassic y... lo mismo. Sigo con que es problema de caché, ¿de Windows?, . Casimiro, estoy contigo, posiblemente en un Linux "pelao" la cosa cambie, de hecho lo probaré por curiosidad. Un saludo y no me harto de agradeceros vuestro interés, muchas gracias |
#26
|
||||
|
||||
¿Y si no está recien arrancado el equipo, si haces un backup/restore también va rápido la primera vez?
|
#27
|
|||
|
|||
Hola, así es, en el momento que hago un backup/restore o ejecuto una vez la consulta va como la seda.
Mi última prueba va a ser con un OpenSUSE y salga lo que salga ahí terminaré. Os cuento resultados. un saludo. |
#28
|
||||
|
||||
Podrias darnos el plan de ejecucion? Cuando mencionas que el producto cartesiano se resuelve rapido, has identificado EXACTAMENTE en que paso esta la demora? El comando EXPLAIN podria dar una luz...
Lo ultimo que se me ocurre es eliminar los indices y triggers antes de la insercion y reagregarlos al final. Tambien, meter los datos en una tabla temporal y de alli traspasarlos. Pero quizas debes analizar esta presentacion sobre desempeño: http://www.slideshare.net/ibsurgeon/...mance-problems
__________________
El malabarista. |
#29
|
||||
|
||||
Cita:
Creo que este tema me va a ser de lo más valioso, ya que tengo una aplicación que presenta una situación muy parecida a la de ARPE1. En mi caso es Windows XP + Firebird 1.5 + Delphi 7 + DBX con el controlador de InterBase (que hasta esa versión de Firebird sí es compatible, según entiendo). El archivo .fdb ocupa unos 535 MB, hago uso adecuado de los índices y pasa lo mismo: con ciertas y muy particulares consultas, la primera vez que las realizo se demora un par de minutos, mientras que haciéndola de nuevo resultan instantáneas. Esto pasa incluso habiendo ya hecho otras consultas y actualizaciones en la base de datos (la conexión puede tener ya varias horas de vida y uso antes de hacer esa primera consulta extrañamente lentificada, o puede ser en cuanto se abre dicha conexión). El problema no ocurre si hago lo mismo desde IBExpert (ahí siempre es rápido) o bien en red. Es decir, sólo pasa cuando ejecuto la aplicación conectándome a la base de datos localmente (misma PC para cliente y servidor). Con IBExpert, ya sea remoto o local, anda rapidísima la consulta. Ya comprobé que la demora no ocurre en el código Delphi. Sino en la llamada que finalmente hace este código a Firebird. ¿Debería pensar en cambiar el controlador DBX InterBase? Extraños saludos. |
#30
|
||||
|
||||
Cita:
Pues no recuerdo si ARPE1 ha mencionado el controlador que usa, vaya a ser algo de eso. |
#31
|
|||
|
|||
Hola
Cita:
Código SQL
Aunque veamos ALMAC NATURAL , no preocupa sólo tiene 40 registros y los lee una vez (analizado con IBExpert). Cita:
Cita:
un saludo y gracias. Última edición por mamcx fecha: 28-11-2012 a las 16:44:22. |
#32
|
|||
|
|||
Cita:
Un saludo. |
#33
|
|||
|
|||
Hola de nuevo, más resultados.
iSQL de firebird (por evitar herramientas de terceros): 1. 1ª vez esos 6 minutos 2. siguientes >>> 3 segundos FDB copiada, tal cual, sobre un SSD. 1. 1ª vez ¡¡¡¡¡ 17 segundos !!!!! 2. siguientes >>> 3 segundos Es curioso, los archivos temporales de FB los tengo redirigidos sobre un mecánico (TempDirectories = G:\FBTemp). Lo único que he hecho ha sido mover el FDB a un SSD. De aquí casi se puede sacar que la caché ¿la guarda en el mismo FBD?. Una pasada el rendimiento, creo que es una buena inversión para los clientes, aunque sea uno pequeño para almacenar sólo el FDB. Y otras cosillas, al tocar lso tamaños de página se reduce algo el tiempo (a más tamaño menos tiempo, al menos en esta consulta). Tampoco para tirar cohetes. Un saludo y os seguiré contando PD. Creo que a estas alturas deberíamos olvidarnos de la consulta SQL y tratar temas de caché, memoria, firebird.conf... es decir de las configuraciones de los sistemas. Voy por SUSE a ver qué me cuenta. |
#34
|
||||
|
||||
IBO es buenecito, aunque IBX y FIBplus son algo más rápidos.
Alguna vez leí o escuché que ibexpert usa, o usaba, IBO. Un par de cosas, ese disco G: es una partición del mismo o es otro disco físico. Debería ser otro disco para mejorar. Si es una partición del mismo entonces estamos en las mismas, no sirve de mucho, más bien de nada. Otra cosa, por probar que no quede, mira de cambiar not exists por not in |
#35
|
|||
|
|||
Hola
Cita:
Cita:
un saludo |
#36
|
|||
|
|||
Hola
Cita:
Un saludo. |
#37
|
||||
|
||||
Cita:
Y por favor, usa el mismo dato para hacer evaluaciones y medidas, si cambias los querys cada vez pues como se puede determinar exactamente la causa? Lo ultimo se me ocurre, es que el disco este fragmentado, o que las estadisticas de los indices esten desincronizadas. El que vuele con SSD muestra en parte eso (los SSD no se fragmentan, y tienen IO superveloz). Es claro, desde mi punto de vista, que FB esta leyendo datos del disco y no desde los indices (en memoria). La 2da vez es rapido porque tiene los planes, indices, etc precalculados y las estadisticas corregidas...
__________________
El malabarista. |
#38
|
||||
|
||||
Ya sé que no va a ser posible, pero no estaría mal tener una copia de la BD para probar
|
#39
|
|||
|
|||
Hola
Cita:
Código SQL [-]Select artic.artic, almac.cod as almac from artic, almac where artic.activo = 'S' and artic.filtro = 'MP' and not exists ( Select artal.artic from artal where artal.artic = artic.artic and artal.almac = almac.cod) Todas las pruebas que os voy poniendo están hechas con la consulta anterior (pensando en un "insert into" en lugar de un "merge"). La tabla "almac" es una auxiliar de código/descripción con clave primaria por código, si no usa ese índice es porque no hay condiciones para el uso y porque necesita todos los registros (en eso consiste la consulta: los artículos seleccionados en todos los almacenes). Cita:
Por cierto no sé a qué te refieres con los tiempos, la consulta la ejecuté con iSQL calculando sólo el plan (Set planonly on). un saludo y gracias por el interés |
#40
|
|||
|
|||
Hola
Cita:
Me gustaría poder compartir más a fondo el problema y las pruebas, pero sabéis que no se puede, si fueran míos los datos pues sí, no habría problema en haceros llegar una copia (¡¡¡de casi 3GB!!!). LOPD, LOPD, LOPD. Con un cantito en los dientes que se me permita tenerla a mi, ¡¡¡menos mal!!!. No sé si podría generar un FDB con las tres tablas implicadas y datos aleatorios hasta llegar al volumen que tienen ellos, y si es así si nos encontraríamos con el mismo problema. Lo estudiaré, de momento me he dado cuenta que tengo el unix muuuuuy olvidado y no soy capaz de echar a andar el fbserver en suse. Un saludo y os sigo poniendo resultados. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
aplicación lenta | Celta | Varios | 2 | 13-01-2012 13:42:19 |
Conexion Con Interbase/FireBIrd lenta...muy lenta | federiconqn21 | Firebird e Interbase | 3 | 11-03-2010 13:13:34 |
Aplicacion lenta | aanil | OOP | 4 | 26-01-2010 15:11:39 |
Ayuda con consulta lenta, lenta, lenta | Gregory Mazon | Firebird e Interbase | 22 | 27-06-2007 09:56:38 |
Impresion lenta, muy lenta... | Perio | Impresión | 2 | 20-05-2005 13:10:00 |
|