"limpiar" registros de rdb$relation_constraints por daño en base de datos

[ContraVeneno]

Que tal

Tengo una base de datos que se dañó y al recuperar el único respaldo disponible, este se recupera sin procedures, triggers ni constraints.

Utilizando la opción "database comparer" de ibexpert, puedo obtener el código de los objetos que "desaparecieron".

Con los procedures y los triggers, no tuve ningún problema para volverlos a poner, pero con los constraints de tipo "check", me marca error:

violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_12" on table "RDB$RELATION_CONSTRAINTS".
Problematic key value is ("RDB$CONSTRAINT_NAME" = 'ACTIVOS_FIJOS_ESTATUS').

Es decir, en la tabla de sistema "RDB$RELATION_CONSTRAINTS" todavía existe el registro, aunque en la tabla a la que pertenece, no existe.

Ya hice un respaldo, mend, sweep, validation y según yo, ya hice todo lo que tengo disponible para "limpiar" la tabla de sistema.

Y como nada de eso me quita esos registros, intenté hacerlo por sql, pero la instrucción "delete" no está permitida para tablas de sistema.

Entonces, la constraint ya no existe en la tabla, pero sigue registrada en la tabla de sistema.

¿qué puedo hacer o cómo podría eliminar esos registros de la tabla "RDB$RELATION_CONSTRAINTS"?

Saludos

[Casimiro Notevi]

No queda muy claro el proceso que has hecho y no podemos probar, tampoco se entiende que restaures una DB y venga sin triggers, sps, etc.
Prueba a desactivar índices antes de restaurar esa tabla, luego lo activas, y si antes ves que hay alguna clave repetida la borras y entonces lo activas.

[ContraVeneno]

Empezado por Casimiro Notevi

No queda muy claro el proceso que has hecho y no podemos probar, tampoco se entiende que restaures una DB y venga sin triggers, sps, etc.
Prueba a desactivar índices antes de restaurar esa tabla, luego lo activas, y si antes ves que hay alguna clave repetida la borras y entonces lo activas.

Pues así tal cual, ja, al restaurar la base de datos no tiene más que las tablas. Supongo que es porque hicieron el respaldo cuando la base de datos tenía algún daño o algún problema.

Ya probé desactivar y activar los índices, pero el problema no está en los índices, ni en las tablas de la base de datos. El problema es que en las tablas de sistema, sigue el registro de un "constraint" que no existe en la tabla que debería tenerlo.



Mi tabla sin check
https://drive.google.com/open?id=1gY...qGSL0XS0Vyki8d


Pero el registro sí existe en la tabla del sistema rdb$relation_constraints, pero no se permite borrar:
https://drive.google.com/open?id=1n6...nJwPQpGShHQ3ls

[mamcx]

No tienes el SQL de creacion de la estructura?

En fin, yo solo exportaria los datos y crearia la estructura aparte en una nueva y luego importo los datos.

[ContraVeneno]

Empezado por mamcx

No tienes el SQL de creacion de la estructura?

En fin, yo solo exportaria los datos y crearia la estructura aparte en una nueva y luego importo los datos.

mmmm...sería exportar casi 20gb de poco más de mil tablas. Y el problema está que no puedo agregar 180 checks. Prefiero seguir buscando la opción de poder insertar el check que me falta y si de plano no encuentro como, tendré que exportar información.

Si te refieres a crear una tabla nueva, exporta la información, luego borrar la tabla vieja y finalmente renombrar la nueva, me marca el mismo error de que ya existe en la tabla de sistema

[Casimiro Notevi]

Lo más cómodo, seguro y fiable es hacer lo que comenta mamcx, creas la estructura de la DB con el script que uses y luego importas los datos, por ejemplo con ibpump.

[mamcx]

Y seguro a la final es menos tiempo que intentar arreglar un archivo corrupto. Ademas que 20GB es poquito*

* Incluso en un disco de 5400 RPM deberia tomar menos de 1 hora toda la vuelta....

[[duilioisola]]

Lo que tienes que hacer es buscar los registros que están en la tabla que no tienen su correspondencia en la otra.

Primero debes identificar las tablas.
una de las tablas es la que tiene el campo ACTIVOS_FIJOS_ESTATUS y la otra tendrás que buscarla, porque mediante el error no puedo saberlo sin la estructura.

Luego tienes que ver qué registros de la tabla no están en la otra a la que hace referencia.

Te pongo un ejemplo para que quede mas claro

ESTADOS
-------
ID  - DESCRIPCION
 1 -  PENDIENTE
 2 -  ENTREGADO
 3 -  FACTURADO   <--- Este registro se pierde
 4 -  IMPRESO

DOCUMENTOS
----------
ID - ID_ESTADO - OTROS_CAMPOS
 1 -    1 - ...
 2 -    3 - ...
 3 -    2 - ...
 4 -    2 - ...
 5 -    4 - ...
...

Imagina que en la tabla ESTADOS se pierde el registro "ESTADO=3".

Deberás buscar los registros de DOCUMENTOS donde no exista una correspondencia con registros de estados.

Código SQL [-]
/* Registris de DOCUMENTOS cuyo ID_ESTADO no está en ESTADOS  */
SELECT * FROM DOCUMENTOS
WHERE
NOT EXISTS(SELECT ESTADO FROM ESTADOS 
           WHERE 
           ID = D.ID_ESTADO)

El resultado sería el siguiente:

DOCUMENTOS
----------
ID - ID_ESTADO - OTROS_CAMPOS
 2 -    3 - ...

Y la solución sería crear ese estado o borrar el documento.

[ContraVeneno]

Gracias a todos por las respuestas

Gracias duilioisola por el aporte, pero el problema no está en la falta de relación entre tablas de la base de datos, si no que el registro se encuentra (encontraba) en la definición de las tablas del sistema.

A final de cuentas se hizo lo que comentó mamcx, con las opciones de "Extract Metadata" se obtiene la estructura de la base de datos y con la opción "Extract Data", se obtienen los datos. Ambas opciones incluidas en el IBExpert.

En este caso en particular, lo más complicado fue establecer el orden en que se exporta la información para mantener las relaciones "Maestro - detalle" de la estructura original, pero cuando conoces ese orden, no es complicado, si no tedioso.

Exportar la estructura no lleva más de 15 minutos. Exportar los datos manteniendo las relaciones necesarias, unas 8 horas más o menos para los 20 gb, entre ir eligiendo el orden y luego la espera de ir insertando información.

A final de cuentas, siguen trabajando con un archivo nuevo.

Saludos y gracias.

[Casimiro Notevi]

Cuando se hacen importaciones masivas, se desactiva primero índices y triggers, se hace la importación y luego se activan. De esa forma es muy rápido.