Consultas IBQuery

[ContraVeneno]

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....

[guillotmarc]

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.

[Casimiro Noteví]

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"

[erickahr]

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.

[guillotmarc]

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.

[roman]

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

[Casimiro Noteví]

Desde luego, una primary key desordenada... como que no