Guía de recuperación de InterBase y Firebird

AVISO: Este documento es el capítulo del libro “El Mundo InterBase” escrito por Alexey Kovyazin y Serg Vostrikov.

El capítulo del libro “El Mundo InterBase” dedicado a la reparación de bases de datos.

1. La historia de esta guía

El libro ruso “El Mundo InterBase” fue publicado en septiembre de 2002.

Su tirada fue de 3000 ejemplares. Después de 3 meses se agotó y la segunda edición mejorada fue publicada en abril de 2003 con una tirada de 5000 ejemplares.

Ahora está en lo más alto de las mayores librerías en línea rusas y tenemos la intención de que se agote muy pronto.

Los autores del libro son Alexey Kovyazin, desarrollador de IBSurgeon y

conocido especialista ruso en InterBase, y Serg Vostrikov, CEO de Devrace

empresa www.devrace.com

Es algo curioso, ¡ni un solo libro dedicado a InterBase ha sido publicado en inglés!

Miles y miles de desarrolladores usan InterBase y Firebird, discuten el

tema en varias conferencias (echa un vistazo aquí: Enlaces).

La comunidad de desarrolladores de InterBase promedia decenas de miles de

personas. La fuerte demanda de libros sobre InterBase en varios países demuestra que la comunidad de InterBase es realmente grande.

Podemos apostar una caja de cerveza a que la edición de 10000 ejemplares se barrería de Amazon.com en un mes. Pero la gente de las editoriales

“lo sabe todo” y están seguros de que nadie comprará un libro sobre InterBase. Es una verdadera lástima.

Aquí nos gustaría ofrecerte el borrador de un capítulo de este libro dedicado a la recuperación de bases de datos InterBase/Firebird.

2. Cómo recuperar una base de datos InterBase/Firebird

2.1. Revisión de las principales causas de corrupción de bases de datos

Desafortunadamente siempre existe la probabilidad de que cualquier almacén de información se

corrompa y se pierda algo de información del mismo. La base de datos no es una excepción a esta regla. En este capítulo consideraremos las causas principales que conducen a la corrupción de bases de datos InterBase, algunos métodos de reparación de bases de datos y extracción de información de las mismas. También conoceremos las recomendaciones y precauciones que minimizarán la probabilidad de pérdida de información de la base de datos.

En primer lugar, si hablamos de reparación de bases de datos deberíamos aclarar la noción de “corrupción de base de datos”. Una base de datos se suele llamar dañada si al intentar extraer o modificar alguna información aparecen errores y/o la información extraída resulta perdida, incompleta o incorrecta. Hay casos en los que las corrupciones de bases de datos están ocultas y solo se encuentran mediante pruebas con herramientas especiales, pero también hay corrupciones reales de bases de datos cuando es imposible conectarse a la base de datos, cuando los programas cliente ajustados muestran errores extraños (cuando no se han ejecutado manipulaciones con la base de datos), o cuando es imposible restaurar la base de datos desde una copia de seguridad.

2.2. Las causas principales de corrupción de bases de datos son:

Terminación anormal del servidor, especialmente interrupción del suministro eléctrico. Para la industria de TI es un verdadero azote y por eso esperamos que no haya necesidad de recordarte una vez más la necesidad de tener una fuente de alimentación ininterrumpida en el servidor.
Defectos y fallos del servidor, especialmente del HDD (disco duro), controladores de disco, memoria principal del ordenador y memoria caché de los controladores RAID.
Una cadena de conexión incorrecta con una base de datos multiusuario de uno o más usuarios (en versiones anteriores a 6.x). Al conectar mediante TCP/IP, la ruta a la base de datos debe indicar nombre del servidor: unidad:/ruta/nombrebasededatos /para servidores en plataforma UNIX nombreservidor: /ruta/nombrebasededatos /, según el protocolo NETBEUI \\nombreservidor\unidad:\ruta\nombrebasededatos. Incluso al conectar la base de datos desde el ordenador en el que se encuentra la base de datos y se ejecuta el servidor, se debe usar la misma línea renombrando nombreservidor por localhost. No se puede usar una unidad asignada en la línea de conexión. Si se rompe una de estas reglas, el servidor considera que trabaja con bases de datos diferentes y la corrupción de la base de datos está garantizada.
Copia de archivos u otro acceso a archivos de la base de datos cuando el servidor está en ejecución. La ejecución del comando “shut-down” o la desconexión de los usuarios de forma habitual no es una garantía de que el servidor no esté haciendo nada con la base de datos, si el intervalo de sweep no está establecido en “0”, se puede ejecutar la recolección de basura. Generalmente la recolección de basura se ejecuta inmediatamente después de que el último usuario se desconecta de la base de datos. Normalmente tarda unos segundos, pero si antes se han confirmado muchas operaciones DELETE o UPDATE, el proceso puede ser más largo.
Uso de versiones inestables del servidor InterBase 5.1-.5.5. La compañía Borland admitió oficialmente que había varios errores en estos servidores y una actualización estable 5.6 se eliminó solo después de la salida de InterBase 6 certificado en modo de ejecución libre para todos los clientes de los servidores 5.1-5.5 en su sitio.
Exceder el límite de tamaño del archivo de base de datos (¡no de la base de datos!). Para versiones anteriores a InterBase 6 y algunas versiones beta de InterBase 6 el límite del archivo de base de datos es 4Gb, para InterBase 6.5 y todas las versiones de Firebird (1.0, 1.5, 2.0, 2.1) - 32Tb. Al acercarse el tamaño de la base de datos al valor límite, se debe crear un archivo adicional.
Agotamiento del espacio libre en disco al trabajar con la base de datos.
Para servidores Borland InterBase versiones anteriores a 6.0.1.6 - exceder la restricción del número de generadores según lo definido por Borland InterBase R & D de la siguiente manera (ver tabla 1).


Versión	Tamaño de página=1024	Tamaño de página=2048	Tamaño de página=4096	Tamaño de página=8192
Anterior a 6	248	504	1016	2040
6.0.x	124	257	508	102

Tabla 1: Número crítico de generadores en versiones tempranas de InterBase

• Para todos los servidores Borland InterBase - exceder el número permitido de

transacciones sin ejecutar backup/restore. Se puede conocer el número de

transacciones ocurridas en la base de datos desde la última creación invocando la utilidad gstat con la clave - h- el parámetro NEXT TRANSACTION ID será la cantidad deseada

de transacciones. Según Ann W.Harrison el número crítico de

transacciones depende del tamaño de página, y tiene los siguientes valores (ver tabla 2):


Tamaño de página de base de datos	Número crítico de transacciones
1024 bytes	131 596 287
2048 bytes	265 814 016
4096 bytes	534 249 472
8192 bytes	1 071 120 384

Tabla 2: Número crítico de transacciones en servidores Borland InterBase

Las restricciones de los servidores Borland InterBase enumeradas anteriormente no se aplican a

los servidores Firebird excepto las primeras versiones 0.x., cuya existencia ya es historia. Si usas la versión final Firebird 1.0 o InterBase 6.5-7.x, no deberías preocuparte por los puntos 5, 6, 8 y 9 y deberías concentrar tus esfuerzos en otras causas. Ahora consideraremos las más frecuentes de ellas en detalle.

2.3. Fallo del suministro eléctrico

Al cortar la alimentación del servidor, todas las actividades de procesamiento de datos se

interrumpen en los lugares más inesperados y (según la ley de Murphy) peligrosos. Como resultado, la información en la base de datos puede distorsionarse o perderse. El caso más simple es cuando todos los datos no confirmados de las aplicaciones de los clientes se pierden como resultado del apagado de emergencia del servidor. Después del reinicio tras el fallo eléctrico, el servidor analiza los datos, detecta transacciones incompletas que no pertenecen a ningún cliente y cancela todas las modificaciones realizadas dentro de los límites de estas transacciones “muertas”. En realidad, tal comportamiento es normal y previsto desde el principio por los desarrolladores de InterBase.

Sin embargo, la interrupción del suministro eléctrico no siempre va seguida de pérdidas tan insignificantes. Si el servidor estaba ejecutando la extensión de la base de datos en el momento de la interrupción del suministro eléctrico, hay una gran probabilidad de tener páginas huérfanas en el archivo de base de datos (páginas que están físicamente asignadas y registradas en la página de inventario de páginas (PIP), en las que la escritura de datos es imposible). Si quieres saber más sobre páginas huérfanas consulta el capítulo «La estructura de la base de datos InterBase».

Solo la herramienta de reparación y modificación gfix (la consideraremos a continuación) es capaz de luchar contra las páginas huérfanas en el archivo de base de datos. En realidad, las páginas huérfanas conducen a un gasto innecesario de espacio en disco y como tales no son la causa de pérdida de datos o corrupción.

La pérdida de alimentación conduce a daños más graves. Por ejemplo, después de cortar la

alimentación y reiniciar, una gran cantidad de datos, incluidos los confirmados, puede perderse (después de añadir o modificar los cuales se ejecutó el comando «commit transaction»). Esto sucede porque los datos confirmados no se escriben directamente en el archivo de base de datos en el disco. Y la caché de archivos del sistema operativo (SO) se utiliza para este fin. El proceso del servidor dio la orden de escritura de datos al SO. Entonces el SO aseguró al servidor que todos los datos estaban guardados en disco y en realidad los datos se almacenaban en la caché de archivos. El SO no tiene prisa por volcar estos datos al disco, porque considera que queda mucha memoria principal y pospone las operaciones lentas de escritura en disco hasta que la memoria principal se llene.

2.4. Escrituras forzadas - un arma de doble filo

Para influir en la situación, se proporciona el ajuste del modo de escritura de datos en InterBase 6. Este parámetro se llama forced writes (FW) y tiene 2 modos - ON (síncrono) y OFF (asíncrono). Los modos FW definen cómo InterBase se comunica con el disco. Si FW está activado, se activa el ajuste de escrituras síncronas en disco, cuando los datos confirmados se escriben en disco justo después del comando commit, el servidor espera la finalización de la escritura y solo entonces continúa el procesamiento. Si FW está desactivado, InterBase no tiene prisa por escribir datos en disco después del comando de confirmación de transacción y delega esta tarea a un hilo paralelo mientras el hilo principal continúa el procesamiento de datos sin esperar a que las escrituras se realicen en disco. El modo de escrituras síncronas es uno de los más cuidadosos y minimiza cualquier posible pérdida de datos, sin embargo puede causar cierta pérdida de rendimiento. El modo de escrituras asíncronas aumenta la probabilidad de pérdida de una gran cantidad de datos. Para lograr el máximo rendimiento, normalmente se establece el modo FW Off. Pero como resultado de una interrupción del suministro eléctrico, se pierde mucha más cantidad de datos durante las escrituras asíncronas que durante las síncronas. Al configurar el modo de escritura, debes decidir si unos pocos porcentajes de rendimiento son más significativos que unas pocas horas de trabajo si la interrupción del suministro eléctrico ocurre inesperadamente.

Muy a menudo los usuarios son descuidados con InterBase. Las pequeñas organizaciones ahorran en cualquier tontería, a menudo en el ordenador-servidor donde se instalan el servidor DBMS y diferentes programas de servidor (y no solo de servidor). Si se cuelgan, la gente sin pensar mucho tiempo pulsa RESET (esto sucede varias veces al día). Aunque InterBase es muy estable ante tales actividades comparado con otros DBMS y permite comenzar a trabajar con la base de datos justo después del reinicio de emergencia, tal uso no es deseable. El número de páginas huérfanas aumenta y los datos pierden conexiones entre sí como resultado de reinicios por fallos.

Esto puede continuar durante mucho tiempo, pero tarde o temprano llegará a su fin. Cuando aparecen páginas dañadas entre las páginas PIP o de generadores, o si la página de cabecera de la base de datos está corrupta, la base de datos puede no abrirse nunca más y convertirse en un gran trozo de datos separados del cual no se puede extraer ni un solo byte de información útil.

2.5. Corrupción del disco duro

Las corrupciones del disco duro conducen a la pérdida de páginas de sistema importantes de la base de datos y/o a la corrupción de enlaces entre las páginas restantes. Tales corrupciones son uno de los casos más difíciles, porque casi siempre requieren intervención de bajo nivel para restaurar la base de datos.

2.6. Errores de diseño de la base de datos

Es necesario que conozcas algunos errores cometidos por los desarrolladores de bases de datos

que pueden llevar a la imposibilidad de recuperación de la base de datos desde una copia de seguridad (*.gbk archivos creados por el programa gbak). En primer lugar, esto es un uso descuidado de las restricciones a nivel de base de datos. Un ejemplo típico son las restricciones NOT NULL. Supongamos que tenemos una tabla llena con un número de registros. Ahora añadiremos a esta tabla usando el comando ALTER TABLE una columna más y señalaremos que no debe contener valores no definidos NULL. Algo así:

ALTER TABLE sometable Field/INTEGER NOT NULL

Y en este caso no habrá error del servidor como se podría esperar. Esta

modificación de metadatos se confirmará y no recibiremos ningún mensaje de error o advertencia, lo que crea una ilusión de normalidad en esta situación.

Sin embargo, si hacemos una copia de seguridad de la base de datos e intentamos restaurarla desde la copia de seguridad, recibiremos un mensaje de error en la fase de restauración (porque se insertan valores NULL en la columna que tiene la restricción NOT NULL, y el proceso de restauración se interrumpirá. (Nota importante proporcionada por Craig Stuntz: con la versión InterBase 7.1, las restricciones se ignoran por defecto durante la restauración (esto se puede controlar mediante un interruptor de línea de comandos) y casi cualquier copia de seguridad no corrupta se puede restaurar. Siempre es una buena idea hacer una restauración de prueba después de hacer una copia de seguridad, pero este problema debería desaparecer en la versión 7.1.) Esta copia de seguridad no se puede restaurar. Si la restauración se dirigió a un archivo con el mismo nombre que la base de datos existente (durante la restauración, el archivo de trabajo de la base de datos existente se estaba sobrescribiendo), perderemos toda la información.

Esto está relacionado con el hecho de que las restricciones NOT NULL se implementan mediante disparadores del sistema que solo verifican los datos entrantes. Durante la restauración, los datos de la copia de seguridad se insertan en las tablas vacías recién creadas; aquí podemos encontrar valores NULL inadmisibles en la columna con la restricción NOT NULL.

Algunos desarrolladores consideran que este comportamiento de InterBase es incorrecto, pero otros no podrán agregar un campo con la restricción NOT NULL a la tabla de la base de datos.

La cuestión sobre el valor requerido por defecto y su relleno en el momento de la creación fue ampliamente discutida por los arquitectos de Firebird, pero no fue aceptada debido al hecho de que el programador obviamente va a llenarlo según un algoritmo bastante complicado y posiblemente iterativo. Pero no hay garantía de si podrá distinguir los registros ignorados por la iteración anterior de los registros sin rellenar o no.

El problema similar puede ser causado por una falla en la recolección de basura debido a la configuración de una ruta incorrecta a la base de datos (la causa de corrupción 3) en el momento de la conexión y el acceso a los archivos de la base de datos cuando el servidor está trabajando con ella (la causa de corrupción 4) y registros completamente llenos con NULL pueden aparecer en algunas tablas. Es muy difícil detectar estos registros, porque no corresponden a las restricciones de control de integridad, y el operador Select simplemente no los ve, aunque entran en la copia de seguridad. Si es imposible restaurar por esta razón, se debe ejecutar el programa gfix (ver más abajo), encontrar y eliminar estos registros usando campos no indexados como condiciones de búsqueda, después de lo cual reintentar hacer una copia de seguridad y restaurar la base de datos desde ella. En conclusión, podemos decir que hay un gran número de causas de corrupción de la base de datos y siempre debe estar preparado para lo peor: que su base de datos se dañe por una u otra razón. También debe estar listo para restaurar y guardar información valiosa. Y ahora consideraremos las precauciones que garantizan la seguridad de la base de datos InterBase, así como los métodos de reparación de bases de datos dañadas.

2.7. Precauciones contra la corrupción de la base de datos InterBase

Para prevenir la corrupción de la base de datos, siempre se deben crear copias de seguridad (si desea saber más sobre las copias de seguridad, consulte el capítulo “Copia de seguridad y restauración”). Es la forma más confiable contra la corrupción de la base de datos. Solo la copia de seguridad da una garantía del 100% de seguridad de la base de datos. Como se describe arriba, como resultado de la copia de seguridad podemos obtener una copia inútil (una copia que no se puede restaurar), por eso la restauración de una base desde la copia no debe realizarse sobrescribiendo el script y la copia de seguridad debe hacerse según reglas definidas. En primer lugar, la copia de seguridad debe ejecutarse con la mayor frecuencia posible; en segundo lugar, debe ser serial; y en tercer lugar, las copias de seguridad deben verificarse para su capacidad de restauración.

A menudo, la copia de seguridad significa que es necesario hacer una copia de seguridad con bastante frecuencia, por ejemplo, una vez cada veinticuatro horas. Cuanto menor sea el período de datos entre las copias de seguridad de la base de datos, menos datos se perderán como resultado de una falla. La secuencia de la copia de seguridad significa que el número de copias de seguridad debe aumentar y debe almacenarse al menos durante una semana. Si hay posibilidad, es necesario escribir las copias de seguridad en dispositivos especiales como un streamer, pero si no la hay, simplemente cópielas a otra computadora. El historial de copias de seguridad ayudará a descubrir corrupciones ocultas y a hacer frente al error que surgió hace mucho tiempo y se manifestó inesperadamente. Hay que verificar si es posible restaurar la copia de seguridad recibida sin errores o no. Solo se puede verificar de una manera: a través del proceso de restauración de prueba. Cabe decir que el proceso de restauración toma 3 veces más tiempo que la copia de seguridad, y es difícil ejecutar la validación de restauración todos los días para bases de datos grandes, porque puede interrumpir el trabajo de los usuarios durante unas horas (la pausa nocturna puede no ser suficiente).

Sería mejor si las grandes organizaciones no ahorraran en “fósforos” y dejaran una computadora para estos fines.

En este caso, si el servidor debe trabajar con una carga seria 24 horas 7 días a la semana, podemos usar el mecanismo SHADOW para tomar instantáneas de la base de datos y posteriores operaciones de copia de seguridad desde la copia inmediata. El proceso de copia de seguridad y restauración de la base de datos se describe en detalle en el capítulo “Copia de seguridad y restauración”. Al crear una copia de seguridad y luego restaurar la base de datos desde ella, se está produciendo la recreación de todos los datos en la base de datos. Este proceso (copia de seguridad/restauración o b/r) contribuye a la corrección de la mayoría de los errores no fatales en la base de datos, conectados con corrupciones del disco duro, detección de problemas de integridad en la base de datos, limpieza de la base de datos de basura (versiones antiguas y fragmentos de registros, transacciones incompletas), disminuyendo considerablemente el tamaño de la base de datos.

El b/r regular es una garantía de seguridad de la base de datos InterBase. Si la base de datos está funcionando, se recomienda ejecutar b/r cada semana. A decir verdad, hay algunas ilustraciones sobre bases de datos InterBase que se usan intensivamente durante años sin copia de seguridad/restauración.

Sin embargo, para estar seguros, es deseable realizar este procedimiento, especialmente porque se puede automatizar fácilmente (consulte el capítulo “Copia de seguridad”).

Si es imposible realizar copias de seguridad/restauraciones frecuentes por algunas razones, entonces se puede usar la herramienta gfix para verificar y restaurar la base de datos. gfix permite verificar y eliminar muchos errores sin b/r.

2.8. Herramienta de línea de comandos gfix

La herramienta de línea de comandos gfix se usa para verificar y restaurar la base de datos. Además, gfix también puede ejecutar varias actividades de control de la base de datos: cambiar el dialecto de la base de datos, establecer y cancelar el modo “solo lectura”, establecer el tamaño de caché para una base de datos concreta y también algunas funciones importantes (puede conocerlas en la Guía de Operaciones de InterBase 6 [4.) gfix se ejecuta en modo de línea de comandos y tiene la siguiente sintaxis:

Gfix [opciones] nombre_db

Opciones: es un conjunto de opciones para ejecutar gfix; nombre_db es el nombre de la base de datos sobre la cual se realizarán las operaciones, definido por el conjunto de opciones. La Tabla 3 representa las opciones de gfix relacionadas con la reparación de la base de datos:


Opción	Descripción
-f[ull]	Esta opción se usa en combinación con -v y significa que es hora de verificar todos los fragmentos de registros
-i[gnore]	La opción hace que gfix ignore errores de suma de verificación en el momento de la validación o limpieza de la base de datos
-m[end]	Marca los registros dañados como no disponibles, como resultado de lo cual serán eliminados durante la siguiente copia de seguridad/restauración. La opción se usa en el momento de preparar la base de datos corrupta para b/r.
-n[o_update]	La opción se usa en combinación con -v para validación de base de datos de solo lectura sin corregir corrupciones
-pas[sword]	La opción permite establecer la contraseña al conectar a la base de datos. (Tenga en cuenta que es un error en la documentación de InterBase -pa[ssword], pero el atajo “-pa” no funcionará - use “-pas”)
-user	La opción permite establecer el nombre de usuario al conectar a la base de datos
-v[alidate]	Opción que preestablece la validación de la base de datos de manera que se descubran errores
-m[ode]	Opción que establece el modo de escritura para la base de datos - para solo lectura o lectura/escritura. Este parámetro puede aceptar 2 valores - read write o read only.
-w[rite] {sync \| async}	Opción que activa y desactiva el modo síncrono/asíncrono de escrituras forzadas a la base de datos. sync - para activar escrituras síncronas (FW ON); async -para activar escrituras asíncronas (FW OFF);

Tabla 1: Opciones de la herramienta gfix para restauración de bases de datos

Hay algunos ejemplos típicos de uso de gfix:

gfix -w sync -user SYSDBA -pass masterkey firstbase.gdb

En este ejemplo establecemos para nuestra base de datos de prueba firstbase.gdb el modo de escrituras síncronas (FW ON). (Por supuesto, es útil antes de que ocurra la corrupción). Y abajo está el primer comando que debe usar para verificar la base de datos después de que ocurra la corrupción:

gfix -v -full -user SYSDBA -pass masterkey firstbase.gdb

En este ejemplo comenzamos a verificar nuestra base de datos de prueba (opción -v) e indicamos que los fragmentos de registros también deben verificarse (opción -full). Por supuesto, es más conveniente establecer varias opciones para el proceso de verificación y restauración mediante cualquier GUI, pero consideraremos las funciones de recuperación de la base de datos usando herramientas de línea de comandos. Estas herramientas están incluidas en InterBase y puede estar seguro de que su comportamiento será el mismo en todos los sistemas operativos que ejecutan InterBase. Es muy importante que siempre estén cerca.

Además, las herramientas existentes que permiten ejecutar la administración de la base de datos desde una computadora cliente usan Services API para ello, que no es compatible con la arquitectura Classic del servidor InterBase. Eso significa que puede usar productos de terceros con la arquitectura de servidor SuperServer.

2.9. La reparación de una base de datos corrupta

Supongamos que hay algunos errores en nuestra base de datos. En primer lugar, tenemos que verificar la existencia de estos errores; en segundo lugar, tenemos que intentar corregir estos errores. Debe seguir las siguientes instrucciones.

Debe detener el servidor InterBase si todavía está funcionando y hacer una copia del archivo o de los archivos de la base de datos. Todas las actividades de restauración deben realizarse solo con la copia de la base de datos, porque el método elegido puede llevar a un resultado desafortunado, y tendrá que reiniciar un procedimiento de restauración (desde un punto de partida). Después de crear una copia, realizaremos la validación completa de la base de datos (verificación de fragmentos de registros).

Debemos ejecutar el siguiente comando para ello:

gfix -v - full corruptbase gdb -user SYSDBA - password

En este caso corruptbase.gdb - es una copia de la base de datos dañada. Un comando verificará la base de datos en busca de cualquier corrupción estructural y dará la lista de problemas no resueltos. Si se detectan tales errores, tendremos que eliminar los datos dañados y prepararnos para la copia de seguridad/restauración usando el siguiente comando:

gfix -mend -user SYSDBA -password your_masterkey corruptbase gdb

Después de ejecutar un comando, debe verificar si quedan algunos errores en la base de datos. Debe ejecutar gfix con las opciones -v -full para ello, y cuando el proceso termine, realizar la copia de seguridad de la base de datos:

gbak -b -v -ig -user SYSDBA -password corruptbase.gdb corruptbase.gbk

Este comando realizará la copia de seguridad de la base de datos (la opción - b lo indica) y obtendremos información detallada sobre la ejecución del proceso de copia de seguridad (opción -v). Los errores relacionados con las sumas de verificación se ignorarán (opción - ig). Si desea obtener más información sobre las opciones de la herramienta de línea de comandos gbak, puede encontrarla en el capítulo “Copia de seguridad y restauración”. Si hay algunos errores con la copia de seguridad, debe iniciarla en otra configuración:

gbak -b -v -ig -g -user SYSDBA -password corruptbase.gdb

corruptbase.gbk

Donde la opción - g desactivará la recolección de basura durante la copia de seguridad. A menudo ayuda a resolver un problema con la copia de seguridad.

También puede ser posible hacer una copia de seguridad de la base de datos si antes establecemos la base de datos en modo de solo lectura. Este modo evita escribir cualquier modificación en la base de datos y a veces ayuda a realizar la copia de seguridad de una base de datos dañada. Para establecer la base de datos en modo de solo lectura, debe usar el siguiente comando: gfix -m read _only

-user SYSDBA -password masterkey Disk:\Path\file.gdb

Después de esto, deberías intentar nuevamente realizar la copia de seguridad de la base de datos utilizando los parámetros indicados anteriormente.

Si la copia de seguridad se realizó correctamente, deberías restaurar la base de datos desde la copia de seguridad. Debes usar el siguiente comando:

gbak -c -user SYSDBA -password masterkey Disk:\Path\backup.gbk

Disk:\Path\newbase,gdb

Al restaurar la base de datos, puedes tener algunos problemas, especialmente al crear los índices. En este caso, se deben agregar las opciones -inactive y -one_at_a_time al comando de restauración. Estas opciones desactivan los índices al crear desde la copia de seguridad y confirman los datos para cada tabla.

2.10. Cómo puedes intentar extraer los datos de una base de datos corrupta

Es posible que las operaciones indicadas anteriormente no conduzcan a la recuperación de la base de datos. Esto significa que la base de datos está seriamente dañada o no puede restaurarse como un todo, o que se deben hacer grandes esfuerzos para su recuperación. Por ejemplo, se puede ejecutar una modificación de los metadatos del sistema, usar funciones no documentadas, etc. Es un trabajo muy duro, prolongado e ingrato con dudosas posibilidades de éxito. Y si es posible, intenta evitarlo y usa otros métodos. Si una base de datos dañada se abre y permite realizar operaciones de lectura y modificación con algunos datos, debes usar esta posibilidad y guardar los datos copiándolos a una nueva base, y “despedirte” de la antigua para siempre.

Entonces, antes de transferir los datos de la base de datos antigua, es necesario crear una base de datos de destino. Si la base de datos no ha cambiado durante mucho tiempo, puedes usar la copia de seguridad antigua, de la cual se pueden extraer los metadatos para crear una base de datos de destino. Sobre la base de estos metadatos, se debe crear un destino de datos y comenzar a copiar los datos. La tarea principal es extraer los datos de una base de datos dañada. Luego tendremos que asignar los datos en una nueva base, pero no es muy difícil, incluso si tenemos que restaurar la estructura de la base de datos desde la memoria. Al extraer datos de las tablas, debes usar el siguiente algoritmo de operaciones:

Primero debes intentar ejecutar SELECT* de la tabla N. Si fue normal, puedes guardar los datos obtenidos en la fuente externa. Es mejor almacenar los datos en un script (casi todas las GUI ofrecen esta función), siempre que la tabla no contenga campos BLOB. Si hay campos BLOB en la tabla, entonces los datos de estos deben guardarse en otra base de datos mediante un programa cliente que actúe como mediador. Quizás tengas que escribir este programa trivial especialmente para fines de recuperación de datos.
Si no pudiste recuperar todos los datos, debes eliminar todos los índices e intentarlo nuevamente. Virtualmente, los índices pueden eliminarse de todas las tablas desde el inicio de la restauración, porque ya no serán necesarios. Por supuesto, si no tienes una estructura de metadatos igual a la corrupta, es necesario ingresar un protocolo de todas las operaciones que estás realizando con la base de datos dañada de origen.
Si no logras leer todos los datos de la tabla después de eliminar los índices, se puede intentar hacer una consulta por rango según la clave primaria. Esto significa elegir un rango definido de datos. Por ejemplo:

SELECT * FROM table N WHERE field_PK >=0 and field_PK <=10000 Field_PK

aquí está la clave primaria. InterBase tiene organización de datos por páginas y por eso la consulta por rango de valores puede ser bastante efectiva, aunque parezca algo así como chamanismo. Sin embargo, funciona porque podemos excluir datos de la consulta de páginas dañadas y leer afortunadamente las demás. Puedes recordar nuestra tesis de que no hay un orden definido de almacenamiento de registros en SQL. Realmente, nadie garantiza que una consulta no ordenada durante reinicios devuelva los registros en el mismo orden, pero no obstante los registros físicos se almacenan dentro de la base de datos en un orden interno definido. Es obvio que el servidor no mezclará los registros solo para cumplir con el estándar SQL. Se puede intentar usar este orden interno para extraer datos de una base de datos dañada (si quieres más información sobre las páginas de datos y sus correlaciones, consulta el capítulo “Estructura de la base de datos InterBase”).

Vitaliy Barmin, uno de los desarrolladores rusos de InterBase con experiencia, informó que de esta manera logró restaurar hasta el 98% de la información de una base de datos irrecuperable (había una gran cantidad de páginas dañadas). Por lo tanto, los datos de una base de datos dañada deben moverse a una nueva base de datos o a fuentes externas como scripts SQL. Al copiar los datos, presta atención a los valores de los generadores en la base de datos dañada (deben guardarse para reiniciar un trabajo adecuado en la nueva base de datos. Si no tienes una copia completa de los metadatos, debes extraer los textos de los procedimientos almacenados, disparadores, restricciones y definiciones de índices.

2.11. Restauración de una base de datos desesperada

En general, la restauración de una base de datos puede ser muy problemática y difícil, y por eso es mejor hacer una copia de seguridad de la base de datos que restaurar los datos dañados, y pase lo que pase, no debes desesperarte porque se puede encontrar una solución en las situaciones más difíciles. Y ahora consideraremos 2 casos.

El primer caso (un problema clásico). Una copia de seguridad que no se puede restaurar debido a que tiene valores NULL en la columna con restricciones NOT NULL (el proceso de restauración se ejecutó sobre el archivo de trabajo). El archivo de trabajo fue borrado y el proceso de restauración se interrumpió debido a un error. Y como resultado de acciones irreflexivas obtuvimos una gran cantidad de datos inútiles (que no se pueden restaurar) en lugar de la copia de seguridad. Pero se encontró la solución. El programador logró recordar qué tabla y qué columna tenían restricciones NOT NULL. El archivo de copia de seguridad se cargó en un editor hexadecimal. Y se encontró allí una combinación de bytes, correspondiente a la definición de esta columna, mediante búsqueda. Después de innumerables experimentos, resultó que la restricción NOT NULL agrega 1 en algún lugar cerca del nombre de la columna. En el editor HEX, este “1” se corrigió a “0” y la copia de seguridad se restauró. Después de ese caso, el programador memorizó de una vez por todas cómo ejecutar el proceso de copia de seguridad y restauración.

El segundo caso. La situación fue catastrófica. La base de datos se corrompió en la fase de extensión debido a la falta de espacio en disco. Al aumentar el tamaño de la base de datos, el servidor crea una serie de páginas críticamente importantes (por ejemplo, página de inventario de transacciones y página de inventario de páginas, páginas adicionales para la relación RDB$Pages) y las escribe al final de la base de datos. Como resultado, la base de datos no se abrió ni con las herramientas de administración ni con la utilidad GBAK. Y cuando intentamos conectarnos a la base de datos, apareció un mensaje de error (“Unexpected end of file”).

Cuando ejecutamos la utilidad gfix, sucedieron cosas extrañas: el programa funcionaba en un ciclo interminable. Cuando gfix estaba trabajando, el servidor escribía errores en el registro (archivo InterBase log) a gran velocidad (alrededor de 100 Kb por segundo). Como resultado, el archivo de registro llenó todo el espacio libre del disco muy rápidamente. Incluso tuvimos que escribir un programa que borrara este registro por temporizador. Este proceso duró mucho tiempo: gfix estuvo trabajando durante más de 16 horas sin ningún resultado. El registro se llenó con errores de la siguiente vista: “Page XXX doubly allocated”. En los códigos fuente de InterBase (en el archivo val.#) hay una breve descripción de este error. Dice que este error aparece cuando la misma página de datos se usa dos veces. Es obvio que este error es el resultado de la corrupción de páginas críticamente importantes.

Como resultado, después de varios días de experimentos desafortunados, se abandonaron los intentos de restaurar los datos de manera estándar. Y por eso tuvimos que usar un análisis de bajo nivel de los datos almacenados en la base de datos dañada.

Alexander Kozelskiy, jefe del departamento de tecnologías de la información de East View Publications Inc, es el autor de la idea de cómo extraer información de bases de datos similares irrecuperables.

El método de restauración que obtuvimos como resultado de las investigaciones se basó en el hecho de que la base de datos tiene organización por páginas y los datos de cada tabla se recopilan en páginas de datos. Cada página de datos contiene el identificador de la tabla para la cual almacena datos. Fue especialmente importante restaurar los datos de varias tablas críticas. Había datos de tablas similares, recibidos de una copia de seguridad antigua que funcionaba perfectamente y podía ser un patrón. La base de datos patrón se cargó en el editor de fuentes hexadecimales y luego buscamos los patrones de esos datos que nos interesaban. Estos datos se copiaron al búfer en formato hexadecimal y luego los restos de la base de datos dañada se cargaron en el editor. Se encontró una secuencia de bytes correspondiente al patrón en la base de datos dañada, y se analizó la página (en la que se encontró esta secuencia).

Primero definimos la página de inicio, pero no fue difícil porque el tamaño del archivo de la base de datos es divisible por el tamaño de la página de datos. Un número del byte actual dividido por el tamaño de página - 8192 bytes, aproxima el resultado a entero (y obtuvimos el número de la página actual). Luego multiplicamos el número de la página actual por el tamaño de página y obtuvimos el número de byte correspondiente al inicio de la página actual. Después de analizar el encabezado, definimos el tipo de página (para páginas con datos, el tipo es 5 - consulta el archivo ods.h del conjunto de fuentes de InterBase y también el capítulo “La estructura de la base de datos InterBase”) así como el identificador de la tabla necesaria.

Luego se escribió un programa que analizaba toda la base de datos, recopilaba todas las páginas de la tabla necesaria en una sola pieza y la movía a un archivo.

Así, cuando obtuvimos los datos que necesitábamos en primer término, comenzamos a analizar el contenido de las páginas seleccionadas. InterBase usa ampliamente la compresión de datos para ahorrar espacio. Por ejemplo, una cadena como VARCHAR que contiene la cadena “ABC”, almacena la siguiente secuencia de valores: longitud de la cadena (2 bytes), en nuestro caso es 0003, y luego los símbolos mismos y luego la suma de verificación. Tuvimos que escribir un analizador de cadenas y otros tipos de datos de la base de datos que convirtiera los datos del formato hexadecimal a una vista ordinaria. Logramos extraer hasta el 80% de la información de varias tablas críticas usando un método “manual” de análisis del contenido de la base de datos. Más tarde, basándose en la experiencia, Oleg Kulkov y Alexey Kovyazin, uno de los autores de este libro, desarrollaron la utilidad InterBase Surgeon que realiza acceso directo a la base de datos, omitiendo el motor InterBase y permite leer directamente e interpretar los datos dentro de la base de datos InterBase de manera adecuada.

Usando InterBase Surgeon, logramos detectar las causas de la corrupción y restaurar hasta el 90% de bases de datos absolutamente irrecuperables que no pueden abrirse con InterBase ni restaurarse con métodos estándar.

Puedes descargar este programa desde el sitio oficial del programa www.ib-aid.com.

3. Agradecimientos

Quisiera agradecer a todos los que me ayudaron a crear esta guía:

Craig Stuntz, Alexander Nevsky, Konstantin Sipachev, Tatjana Sipacheva y todas las demás personas amables y conocedoras de la comunidad de InterBase y Firebird.

Si tienes alguna sugerencia o pregunta sobre este capítulo, no dudes en enviar un correo electrónico.