Copia de seguridad muy lenta
 

Situación:

Tengo una base de datos de firebird 1.5.3, sobre un servidor linux, ocupa 2,4 Gb.

1. Saco copia de seguridad, tarda 10 minutos
2. Vacio dos tablas que tienen una 400k y otra 2M de registros, tarda 1/2 hora en ejecutar el borrado.
3. Saco copia de seguridad y tarda ¡ 8 horas!

¿Qué puedo hacer para reducir el tiempo de la segunda copia? ¿Qué hago mal? ¿Hay que ejecutar algún proceso?

Gracias de antemano.

Revisa que en la primera copia de seguridad no estés eliminando los índices de la base de datos.

No, en ningún caso se modifica el metadata, ni se desactivan índices ni nada, con las tablas vacías tarda un disparate.

¿Y cómo haces las copias?, ¿a dónde haces la copia?, ¿con qué comando o programa las haces?...
¿Media hora en borrar unos datos?, ¿seguramente se estén ejecutando triggers y procedimientos lanzados en esos borrados?, ¿cómo borras los datos?, ¿cómo borras la tabla?...
¿Las copias son del disco al mismo disco?, ¿a otro disco?, ¿a un disco externo?, ¿scsi, usb, ide...?, ¿haces las copias en otro ordenador por la red?, ¿otro linux, windows...?, ¿de qué forma, sistema, etc...? :)
En fin, que bastante difícil es ayudar en estos casos como para que des tan poquita información :)

Hola foro,

He tenido un caso similar con un una base de datos en un cliente y lo que puedo concluir es que Firebird 1.5.x es demasiado sensible a la eliminación másiva de registros.

Cuando se eliminan cientos de miles de registros y se hace backup he observado con IBExpert (poniendo el Backup en modo Verbose por pantalla para ir viendo que esta haciendo) que las tablas donde se ha hecho eliminacion masiva se demora cantidades alarmantes de tiempo.

Supongo que el problema esta en el sistema de paginacion de Firebird pues las paginas donde estaban los registros borrados quedan disponibles para ser utilizadas por registros nuevos. Cuando se hace un backup es como si tuviera que recorrer todas las paginas esten libres o no pero el recorrido por esas paginas mucho más.

Algo lei (no recuerdo donde) que la version 2.0 de Firebird haria mucho más rapido el proceso de backup, puedes hacer una pruebas a ver como te va con dicha version.

Las copias las he probado de diferentes formas, Programas: gbak, IbExpert o programa propio con IBX, ninguna diferencia.

Estos procesos los realizo siempre con servidores Linux, con Windows no he sido capaz de soportar los tiempos de espera, o se queda sin memoria.

¿Cómo los borro? normalmente desde isql o IbExpert con "delete from xxx" y borra 400k registros de xxx más dos millones por integridad referencial de yyy.

La base de datos y la copia SIEMPRE están en el mismo disco, incluso en dos con raid, osea el mismo, pero siempre disco interno IDE/SATA.

El problema es que no puedo vaciar una tabla y realizar copia, de una forma razonable, borrar los registros es un tiempo razonable, pero crear la copia posterior es cuando se alarga horas.

Por supuesto la base de datos comprobado de posibles errores, la tabla de xxx tiene 18 índices no demasiado complejos, sobre todo con integer, y la yyy 5 o 6.

Las bases de datos tienen un tamaño de página de 8Kb normalmente.

Ahora estamos trabajando en desarrollar una versión para FB 2.0, ya que tenemos algún problema, sobre todo con las UDF y sus parámetros que han cambiado de CHAR a VARCHAR, cuando tenga que convertir alguna de esas bases de datos grandes(con las de tamaño inferior este problema no existe) podré hacer una prueba.

Gracias por vuestras respuestas.

ufff... es tan difícil poder ayudar en algo así cuando no podemos ver y tocar la situación real...

Una pregunta: ¿los datos que borras son todos los registros de una tabla?, si es así, en lugar de borrar los registros, mejor te resultará borrar la tabla (drop tabla) y luego volver a crearla.

¿Puedes pasarnos el metadata de la base de datos?, también alguna información para poder recrear una situación habitual de tus datos, a ver si así podemos sacar algo en claro.

Los datos borrados no son todos los de una tabla, es un proceso de inicio de ejercicio de una base de datos, y siempre contiene datos que deben mantenerse, normalmente los del ejercicio n-1 más de los del n, borrando los anteriores a n-1, con lo que aproximadamente se borran algo menos de la mitad de los registros.

Tabla maestro:

CREATE TABLE TABLA_MAESTRO (
ID ID NOT NULL /* ID = INTEGER */,
NR NR NOT NULL /* NR = VARCHAR(15) NOT NULL */,
NPLAN NRPLAN /* NRPLAN = VARCHAR(32) */,
NTRANSACCION ID /* ID = INTEGER */,
ORIGEN ID /* ID = INTEGER */,
MEDIO ID /* ID = INTEGER */,
DESTINO ID /* ID = INTEGER */,
OBJETO ID /* ID = INTEGER */,
RESPONSABLE ID /* ID = INTEGER */,
COEFICIENTE COEFICIENTE /* COEFICIENTE = NUMERIC(14,4) DEFAULT 0 */,
FECHAINICIO FECHA /* FECHA = TIMESTAMP */,
FECHAINICIOPLANIFICADA FECHA /* FECHA = TIMESTAMP */,
FECHAFIN FECHA /* FECHA = TIMESTAMP */,
FECHAFINPLANIFICADA FECHA /* FECHA = TIMESTAMP */,
SUBFAMILIA ID NOT NULL /* ID = INTEGER */,
SUBFAMILIAMETODO ID /* ID = INTEGER */,
CONTENIDO ID /* ID = INTEGER */,
INIVAL FECHA /* FECHA = TIMESTAMP */,
FINVAL FECHA /* FECHA = TIMESTAMP */,
FECHAREGISTRO FECHA_NOW /* FECHA_NOW = TIMESTAMP DEFAULT 'NOW' */,
FECHAMODIFICACION FECHA_NOW /* FECHA_NOW = TIMESTAMP DEFAULT 'NOW' */,
FECHAENVIO FECHA /* FECHA = TIMESTAMP */,
RS RS /* RS = SMALLINT DEFAULT 0 */,
ORDEN ORDEN /* ORDEN = VARCHAR(15) */,
NUMDOCUMENTO1 PROPIEDAD /* PROPIEDAD = VARCHAR(50) */,
NUMDOCUMENTO2 PROPIEDAD /* PROPIEDAD = VARCHAR(50) */,
NUMDOCUMENTO3 PROPIEDAD /* PROPIEDAD = VARCHAR(50) */,
ESTADO ESTADO_LINEA /* ESTADO_LINEA = SMALLINT */
);




/******************************************************************************/
/**** Primary Keys ****/
/******************************************************************************/

ALTER TABLE TABLA_MAESTRO ADD CONSTRAINT PK_TABLA_MAESTRO PRIMARY KEY (ID);


/******************************************************************************/
/**** Foreign Keys ****/
/******************************************************************************/

ALTER TABLE TABLA_MAESTRO ADD CONSTRAINT FK_TABLA_MAESTRO FOREIGN KEY (SUBFAMILIA) REFERENCES PLN_LISTAFAMILIA (ID) ON DELETE SET NULL ON UPDATE CASCADE;
ALTER TABLE TABLA_MAESTRO ADD CONSTRAINT FK_TABLA_MAESTRO2 FOREIGN KEY (NTRANSACCION) REFERENCES SIE_JERARQUIA (ID) ON DELETE SET NULL ON UPDATE CASCADE;
ALTER TABLE TABLA_MAESTRO ADD CONSTRAINT FK_TABLA_MAESTRO3 FOREIGN KEY (RESPONSABLE) REFERENCES GRH_DEFINICION (ID);


/******************************************************************************/
/**** Indices ****/
/******************************************************************************/

CREATE UNIQUE INDEX TABLA_MAESTRO_IDX1 ON TABLA_MAESTRO (NR);
CREATE INDEX TABLA_MAESTRO_IDX10 ON TABLA_MAESTRO (SUBFAMILIAMETODO, ORDEN, ID);
CREATE INDEX TABLA_MAESTRO_IDX11 ON TABLA_MAESTRO (OBJETO);
CREATE INDEX TABLA_MAESTRO_IDX12 ON TABLA_MAESTRO (NUMDOCUMENTO1);
CREATE INDEX TABLA_MAESTRO_IDX13 ON TABLA_MAESTRO (NUMDOCUMENTO2);
CREATE INDEX TABLA_MAESTRO_IDX14 ON TABLA_MAESTRO (NUMDOCUMENTO3);
CREATE INDEX TABLA_MAESTRO_IDX15 ON TABLA_MAESTRO (SUBFAMILIA, SUBFAMILIAMETODO);
CREATE INDEX TABLA_MAESTRO_IDX2 ON TABLA_MAESTRO (FECHAMODIFICACION);
CREATE DESCENDING INDEX TABLA_MAESTRO_IDX3 ON TABLA_MAESTRO (NPLAN, FECHAINICIO);
CREATE DESCENDING INDEX TABLA_MAESTRO_IDX4 ON TABLA_MAESTRO (FECHAINICIO);
CREATE INDEX TABLA_MAESTRO_IDX5 ON TABLA_MAESTRO (FECHAFIN);
CREATE INDEX TABLA_MAESTRO_IDX6 ON TABLA_MAESTRO (ORIGEN);
CREATE INDEX TABLA_MAESTRO_IDX7 ON TABLA_MAESTRO (DESTINO);
CREATE INDEX TABLA_MAESTRO_IDX8 ON TABLA_MAESTRO (MEDIO);
CREATE INDEX TABLA_MAESTRO_IDX9 ON TABLA_MAESTRO (RESPONSABLE, SUBFAMILIA);


Tabla detalle:

CREATE TABLE TABLA_DETALLE (
ID ID NOT NULL /* ID = INTEGER */,
NRP NR NOT NULL /* NR = VARCHAR(15) NOT NULL */,
NR NR NOT NULL /* NR = VARCHAR(15) NOT NULL */,
TIPOPROPIEDAD ID NOT NULL /* ID = INTEGER */,
PROPIEDAD PROPIEDAD /* PROPIEDAD = VARCHAR(50) */,
INIVAL FECHA /* FECHA = TIMESTAMP */,
FINVAL FECHA /* FECHA = TIMESTAMP */,
FECHAREGISTRO FECHA_NOW /* FECHA_NOW = TIMESTAMP DEFAULT 'NOW' */,
FECHAMODIFICACION FECHA_NOW /* FECHA_NOW = TIMESTAMP DEFAULT 'NOW' */,
FECHAENVIO FECHA /* FECHA = TIMESTAMP */,
RS RS /* RS = SMALLINT DEFAULT 0 */
);




/******************************************************************************/
/**** Primary Keys ****/
/******************************************************************************/

ALTER TABLE TABLA_DETALLE ADD CONSTRAINT PK_TABLA_DETALLE PRIMARY KEY (ID);


/******************************************************************************/
/**** Foreign Keys ****/
/******************************************************************************/

ALTER TABLE TABLA_DETALLE ADD CONSTRAINT FK_TABLA_DETALLE FOREIGN KEY (TIPOPROPIEDAD) REFERENCES PLN_TIPOPROPIEDAD (ID) ON DELETE SET NULL ON UPDATE CASCADE;


/******************************************************************************/
/**** Indices ****/
/******************************************************************************/

CREATE UNIQUE INDEX TABLA_DETALLE_IDX1 ON TABLA_DETALLE (NR, TIPOPROPIEDAD);
CREATE INDEX TABLA_DETALLE_IDX2 ON TABLA_DETALLE (FECHAMODIFICACION);
CREATE UNIQUE INDEX TABLA_DETALLE_IDX3 ON TABLA_DETALLE (NRP);
CREATE INDEX TABLA_DETALLE_IDX4 ON TABLA_DETALLE (NR, TIPOPROPIEDAD, PROPIEDAD);




En realidad el borrado de los registro de la tabla detalle, se produce por un trigger, pero como ya he dicho en los post anteriores, el tiempo de borrado es asumible, el problema es la copia de seguridad.


La tabla maestro contiene unos 900k de registros, de los cuales son borrados 400k, y la detalle unos 5M, de los que se borran algo más de 2.

Resp
 

Un solucion podrian ser que antes de sacar el respaldo hagan u sweep para limpiar la base de datos de trasnsacion en el limbo, borrados etc. Y luego haces tu respaldo. Aunque puedes usar mas opciones es le respaldo que te pueden ayudar a aumentar la velocidad.

Pero con la experiencia que he tenido ultimandamente he montado firebird en linux y no en window y la diferenci aes del cielo a la tierra. Y segun saque mis concluiones los problemas de firebird en windows la mayoria no son del firebiord si no que el problema lo ocasiona el sistema oprativo(ojo: windows me ha dado de comer por mucho tiempo).

No es que lo estoy mandado hacia linux. Pero debiaraina hacerlo. Ya ultimadamente es lo que estoy usando y hay que ver que se porta de maravilla. No solo con firebird si no esn todo samba, apache, iptables(me quito mil dolores de cabeza) entre otros.

Asi que animenese a probar linux.

Creo que he hayado una solución, precisamente va por el tema del sweep, hay un parámetro -G(ARBAGE_COLLECT), que INHIBE la recolección de basura, he visto que es el mismo proceso que el SWEEP, pues bien, si activo este parámetro la copia tarda 10-20 minutos (en un Pentium 4 2.4 con Fedora Core 3 y una base de datos de 4Gb).

Lo que me sorprendió es que según la descripción del proceso, recorre y elimina las tablas asignadas con registros borrados, vacia el limbo, etc., con su consiguiente reducción de espacio, sin embargo yo lo tengo desactivado, ¿eso significa que lo hace sobre el original?, porque la copia de seguridad al restaurarse disminuye su tamaño considerablemente, a pesar de inhibir la recolección de basura.

En cualquier caso, creo que puede servir como solución.

Gracias a todos y espero que sirva este post a mucha gente.

Otra solución: Exporta los registros que quieres conservar a una tabla temporal, hazle un drop la tabla original, vuelve a crearla e importa los registros de la tabla temporal. Es sin duda más rapido.