![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Aunque no estoy convencido de ello, intenta preparar la query antes de abrirla, la query tiene un metodo llamado Prepare,
por otra parte intenta remplazar el MDOQuery por un MDODataset asignando la string de la SQL de la primera a la SelectSQL de la segunda.. Has mirado si esta linea existe tb en los Fibplus? |
|
#2
|
|||
|
|||
|
Cita:
Gracias Delfino por tu ayuda. He hecho un prepare como me dices y el problema sigue. En cuanto a reemplazar el mdoquery por el mdodataset no ha lugar, porque siempre he usado mdodataset; es decir, el problema lo da con el mdodataset (aunque la línea del parón esté en una unidad llamada MDOSQL.prepare, esa unidad la llama mdodatset). He mirado, pero muy por encima, y no encuentro esa línea en los fibplus. Un saludo. |
|
#3
|
|||
|
|||
|
Mismo problema
Que tal
Yo también tengo el mismo problema que Angel, yo utilizo Delphi7, DBExpress, Firebird 1.554926. La primera consulta me tarda aproximadamente 30 segundos, después de eso se ejecutan en un tiempo normal de menos de un segundo. Mis tablas no rebasan el millón de registros, apenas lo están alcanzando: 935,113. El tamaño de la base de datos es de 400 MB Intenté con otros componentes de conexión para probar si DBExpress era la causa, pero no fue así. Ya probé la opción que da Al sobre la afinación a los índices pero no solucionó el problema. Haré algunas pruebas con Linux para poder culpar sin dudas a Windows y también haré las pruebas aisladas que comenta Al. Saludos. Bismarck |
|
#4
|
|||
|
|||
|
Cita:
¿Has probado con FIBPLUS? Yo he probado y ha desaparecido el parón aunque, extrañamente, hay alguna otra lentitud en momentos muy puntuales, pero no soy capaz de detectar un hilo conductor. De todos modos, con fib ha mejorado considerablemente. Mi BD tiene 6 millones y pico de datos y ocupa más de un 1.5 GB. Estoy un poco asustado porque ahora mismo tenemos datos de 3 meses. Cuando tengamos todo un año de datos tendremos una base de 4.5 Gb aprox. En windows un fichero tan grande se fragmenta muchísimo y hay que estar desfragmentando cada semana. Si en linux esto no ocurre, puede ser un puntazo a favor. Los deberes que me puso Al, siento decir que aún no me he puesto con ello. Es final de curso y tengo muchísimo trabajo. A ver si en 15 días hago las pruebas. Un saludo. |
|
#5
|
|||
|
|||
|
¡Lo he solucionado (creo)!
Compañeros:
He logrado solucionar el problema... de forma accidental, como se logran los mayores avances en la ciencia. Aún no he tenido tiempo de hacer las pruebas que el maestro Al me puso como deberes (este final de curso se está complicando demasiado; por poner un ejemplo, casi pierdo mi puesto de trabajo y aún no está todo solucionado) pero trasteando con otras cosas creo haber hallado la solución. La solución pasa por hacer un gbak y luego restaurar la base de datos con un tamaño de página muy grande; yo le he puesto el mayor: 16384. Con esto he logrado hacer desaparecer la lentitud en la consulta a la tabla de sensores. Y no sólo eso: una consulta muy complicada que sobre una base FDB con tamaño de página de 1024 tarda más de 7 minutos, he logrado reducirla a menos de dos minutos con la base FDB con tamaño de página de 16384. Una advertencia: quizá esta solución no sirva para cualquier base fdb. Mi base es enorme: ahora mismo tiene unos 7 millones de registros y ocupa en disco 1,2 GB. Estoy hablando de una base fdb sobre Win XP SP2, usando firebird 2.0 y Delphi 7. Espero haber ayudado a otra gente con el mismo problema. Un saludo para todos y muchísimas gracias a todos los que me habéis ayudado. |
|
#6
|
|||
|
|||
|
Podemos entender q el problema no tenia q ver con componentes?
y eso de q con FibPlus se soluciono y con los otros no? a Ver si das mas detalles ![]() |
|
#7
|
|||
|
|||
|
Cita:
Hay que recordar que el problema ocurría sólo la primera vez que se accedía a la tabla. Las veces sucesivas todo iba como la seda. Lo que sí puedo decir al 90% (no al 100% porque no he hecho muchas pruebas) es que aumentando el tamaño de paginación de la BD el acceso mejora y mucho. Ya no tengo esa demora de 30 segundos en el primer acceso a la tabla. Ahora es de menos de 1 segundo. He hecho varias pruebas y va bien. Pero muchísimo mejor. Todas las consultas tardan menos de la mitad de tiempo. Tengo que añadir una cosa que enturbia un poco esto que digo: también le he aumentado la ram a mi ordenador. De 1 GB he pasado a tener 2,5 GB. Sin embargo, con 2,5 GB he hecho pruebas con la base de datos con tamaño de página de 1024 y vuelve a ser lento todo. Con lo cual concluyo que sin duda el aumento de ram ayuda y mucho, pero el problema se ha "resuelto" con el aumento del tamaño de página. (Pongo "resuelto" entre comillas porque parece que no me lo termino de creer). Os iré diciendo si hago más pruebas y logro sacar más conclusiones. Un saludo. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Ayuda con consulta lenta, lenta, lenta | Gregory Mazon | Firebird e Interbase | 22 | 27-06-2007 09:56:38 |
| Consulta sencilla sobre ms access | fybeyancourt | Tablas planas | 2 | 05-03-2007 22:51:58 |
| Error raro en consulta sencilla | papulo | SQL | 1 | 16-09-2005 10:41:42 |
| Consulta Sencilla SQL + Delphi | Maury Manosalva | SQL | 4 | 08-09-2005 11:17:47 |
| Consulta muy lenta | Walterdf | Conexión con bases de datos | 2 | 25-08-2004 18:37:57 |
|