FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Consultas IBQuery
Hola a todos y gracias de antemano, tengo una tabla de firebird de la cual debo eliminar una gran cantidad de registros (+ de 1000,000 ), la cosa es que la eliminacion me va muy lenta, quisiera saber si hay una forma mas rapida de hacerlo o como me recomiendan relizar la eliminacion, mi codigo esta algo asi:
select * from remision where fecha <= :xFecha; luego de filtrar hago la eliminacion mediante un while not EOF do begin delete; next; end; funciona todo bien pero lo he dejado correr mas de 3 horas y no termina... segun mis calculos elimina 1000 registros en aproximadamente una hora ... ojala me puedan ayudar...
__________________
Nadie puede separar su fe de sus actos, o sus creencias de sus afanes |
#3
|
||||
|
||||
Gracias por tu pronta respuesta... de hecho fue mi primer opcion pero al ver la problematica (lentitud) estuve leyendo po ahi y encontre el bucle, y hago un commit cada 1000 registros para no saturar el cache.. pero aun asi sigue lentisimo y solo quiesiera saber si hay otro metodo ojala tengas algo , gracias otra vez
__________________
Nadie puede separar su fe de sus actos, o sus creencias de sus afanes Última edición por roman fecha: 02-03-2010 a las 02:02:33. Razón: Agregar etiquetas [delphi para mayor legibilidad del código |
#4
|
||||
|
||||
Bueno, mira, yo no conozco Firebird pero podría jurar que la consulta DELETE siempre va a ser más rápida y eficiente que un ciclo, pues este ciclo, muy posiblemente se limite a hacer un DELETE sobre cada uno de los registros.
Ahora bien, aunque, como te digo, no conozco Firebird, se me ocurren dos considerandos generales que podrían ayudar: primero asegurarte que tu tabla tiene un índice sobre el campo fecha, pues de esta manera, el motor encontrará mucho más rápido los registros que debe borrar. Segundo, si lo anterior no funciona, entonces quizá debas probar desactivando los índices. Toma en cuenta que si tu tabla tiene definidos muchos índices, todos ellos deben actualizarse al borra registros. // Saludos |
#5
|
||||
|
||||
pues no se lo que los demas opinen, pero creo que un ciclo While con su respectiva transacción (commit) es mil veces más lenta que la instrucción delete que propone maese Roman....
__________________
|
#6
|
||||
|
||||
Hombre está claro que un DELETE va a ir más rápido que un WHILE, puesto que al primero le dejas total libertada al motor SQL para definir el recorrido del borrado, etc. ...
Pero la diferencia será mínima, y desde luego no puede explicar una demora de horas para hacer ese borrado. En mi opinión estoy convencido de que tu problema vienen dado por los triggers que tienes en esa tabla. Cada vez que borras un registro (independientemente de si lo has borrado con un DELETE o mediante un bucle), se dispara el trigger correspondiente, el cual debe hacer un montón de cálculos, por lo que parece. Si esto lo multiplicas por los 100.000 registros que quieres borrar, pues de ahí viene esa lentitud. Resumiendo, olvídate de como haces el borrado y examina lo que hacen los triggers que se disparan para cada registro borrado. Quizás quieras desactivar esos triggers antes de empezar el borrado.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#7
|
||||
|
||||
Evidentemente el "delete" es más rápido que el bucle, pero estoy con guillotmarc en que deben existir triggers o procedimientos que se ejecutan al borrar, debes desactivarlo antes y verás que se borra todo en un "santiamén"
|
#8
|
||||
|
||||
Gracias a todos, Sobre todo a ROMAN!!!
Pues muchas gracias a todos por sus respuestas, y por su tiempo... en realidad Roman tuvo la razon desde el principio, el Delete fue la mejor opcion, solo que tenia un problma con las PrimaryKey, estaban desordenadas, al checarlas las arregle y corrio del 1, los triggers no los puedo desactivar como aconseja casimiro, porque los necesito para eliminar registros de una tabla relacionada a remision, pero arreglando las llaves primarias y los indices, bajo de 8 horas a un par de segundos, "Roman cuando sea grande quiero ser como tu" jaja, saludos y gracias.
__________________
Nadie puede separar su fe de sus actos, o sus creencias de sus afanes |
#9
|
||||
|
||||
Hola.
Felicidades por resolver el problema, pero la explicación que has dado es errónea, puede llevar a confusión a otra persona que llegue hasta aquí por un problema similar. Algo más de lo que te sugirió Román has hecho, puesto que lo que dices no tiene sentido, es harto difícil de creer. Es imposible que un delete from remision where fecha <= :xFecha te tarde ocho horas, añadas un índice sobre el campo Fecha (que es el índice que te sugirieron crear ya que es el único campo que interviene, no la clave primaria) y milagrosamente ese borrado pase a tardar dos segundos. Simplemente no puede ser, si el motor SQL no encuentra un índice para Fecha, se ve obligado a recorrer toda la tabla buscando las fechas menores a cierto valor. Pero eso puede tardar un par de minutos (como máximo), nunca ocho horas. NOTA: Resulta evidente que has solucionado el problema mediante índices sobre las tablas secundarias que son borradas en triggers. Así que no te equivoques, tu problema estaba en esos triggers, en lo que tardaban en ejecutarse al no estar debidamente optimizados (lo cual, como te dijimos, multiplicado por 100.000 registros a borrar, es lo único que puede explicar un tiempo de ejecución de ocho horas). PD: Las Primary Keys siempre están ordenadas, puesto que siempre existe un índice para la clave primaria que definas en la tabla (ese índice lo crea automáticamente el sistema). Tú te estas refiriendo a que has creado índices para las Foreign Keys, es decir, las referencias en tus tablas secundarias que apuntan a la tabla a borrar. Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). Última edición por guillotmarc fecha: 03-03-2010 a las 17:32:19. |
#10
|
||||
|
||||
Yo concuerdo con marc; hay algo que no termina de cuadrar. ¿Cómo está eso de que las llaves primarias estaban desordenadas? Una llave primaria no puede estar desordenada, o qué motor de pacotilla es Firebird .
Creo, como marc, que seria conveniente que explicaras con más detalle lo que hiciste para resolver el problema. // Saludos |
#11
|
||||
|
||||
Desde luego, una primary key desordenada... como que no
|
#12
|
||||
|
||||
Sorry!!!
OK si perdon, creo que no me explique bien, al decir las
Cita:
TABLA DE_REM
TABLA REMISION
Los Scripts que muestro son los definitivos, como ha funcionado mi consulta rapidamente, el problema radicaba en que tenia mal declarados los PK e Indices. ejemplo: En la tabla remision tenia algo asi: (IDTIENDA, IDREMISION); En la tabla de_rem : (ID, IDREMISION, IDTIENDA); Segun lei, al hacer esto era como si no existieran los indices ni nada, tenia que declararlos con el mismo orden en las dos tablas. el Trigger implicado es este:
Una disculpa nuevamente a todos, y Cita:
__________________
Nadie puede separar su fe de sus actos, o sus creencias de sus afanes |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Consultas SQL V.S. Consultas Clipper | AGAG4 | SQL | 7 | 20-12-2005 15:59:31 |
Refresh de un IBQuery | perillan | Conexión con bases de datos | 1 | 28-08-2005 20:43:12 |
Filter en IBQuery | StartKill | Firebird e Interbase | 1 | 27-08-2005 06:51:06 |
IBDataSet - IBQuery | dmagui | Firebird e Interbase | 0 | 14-06-2005 16:24:40 |
query Vs. IBquery | Eolo | Conexión con bases de datos | 0 | 11-02-2004 18:54:24 |
|