internal gds software consistency check (invalid block type encountered (147))

StartKill · #1 22-07-2004

Hola Club,

Los errores nos persiguen...

*Trabajo con Delphi 7.0
*Interbase 6.0.1
*Controles IBX
*EMS firebird/Interbase

Manifestarles que tenemos una Base de datos donde se ha creado un Usuario "GRILLO"

con este usuario se empezó creando tablas, indices, constrains....

El asunto es que somos tres programadores que utilizamos el mismo usuario para acceder a base de datos y cada uno de nosotros modifica segun las necesidades que se presenten.

Utilizamos el EMS firebird/Interbsase para dicha labor, peroooo de en estos ultimos dias se nos a empezado a desconectarse el interbase, y revisando el archivo de log encontramos esto:

Código:

XEON (Server)	Thu Jul 22 13:15:38 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

XEON (Server)	Thu Jul 22 13:16:22 2004
	INET/inet_error: read errno = 10054

XEON (Server)	Thu Jul 22 13:16:43 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

XEON (Server)	Thu Jul 22 13:16:49 2004
	INET/inet_error: read errno = 10054

XEON (Server)	Thu Jul 22 13:20:15 2004
	INET/inet_error: read errno = 10054

XEON (Server)	Thu Jul 22 13:25:36 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	Page 6459 is an orphan

XEON (Server)	Thu Jul 22 13:25:36 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	Page 6460 is an orphan

XEON (Server)	Thu Jul 22 13:25:36 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	Page 6461 is an orphan

XEON (Server)	Thu Jul 22 13:26:04 2004
	INET/inet_error: read errno = 10054

XEON (Client)	Thu Jul 22 13:46:37 2004
	Guardian starting: C:\Archivos de programa\Borland\InterBase\bin\ibserver.exe

En el EMS se nos presenta la cajita de dialogo asi:

Código:

internal gds software consistency check...

y perdemos la coneccion, al volver conectarnos aparentemente esta bien la base de datos pero al empezar a revisar nuestro datos (sobre todo los ultimos campos, generadores, trigers) vuelve a saltar el error:

Código:

internal gds software consistency check...

Perdiendo nuevamante la conexion.

No se como reparar este error y lo que hacemos es restaurar una copia de la BDD...

Sera por que accedemos los tres programadores al mismo tiempo..modificando la base de datos??

Si fuera el caso como podriamos trabajar los tres al mismo tiempo???

Espero sugerencias, regalos y otros que sera bienvenidos.

Gracias de antemano

Your friend,

StartKill
Lima-Peru

guillotmarc · #2 22-07-2004

Hola.

El mensaje indica que tienes la base de dades corrompida, la solución normalmente pasa por restaurarla de una copia.

Aunque como dices que eso ya lo has hecho, probablemente algún proceso que ejecutas te corrompe la base de datos.

Te recomiendo que restaures la base de datos en un servidor Firebird en lugar de Interbase, puesto que también es open source/gratuito y tiene muchos errores de Interbase 6 corregidos.

NOTA: Naturalmente puedes tener perfectamente 3 programadores accediendo concurrentemente a la base de datos.

Saludos.

Neftali [Germán.Estévez] · #3 23-07-2004

Cita:

Empezado por StartKill

No se como reparar este error y lo que hacemos es restaurar una copia de la BDD...

Sera por que accedemos los tres programadores al mismo tiempo..modificando la base de datos??

Si fuera el caso como podriamos trabajar los tres al mismo tiempo???

Espero sugerencias, regalos y otros que sera bienvenidos.

En lugar de recuperar la copia directamente, ¿porqué no probáis a recuperar/reparar la BD que tenéis? ¿Talvez la copia que estéis restaurando tb tenga algo mal?
En el directorio BIN de Interbase tienes dos aplicaciones (de ms-dos) que te pueden ayudar. GFIX te permite reparar Bases de Datos con errores y GBAK es para el tema de copias de seguridad. En la documentación de Interbase (OPGUIDE) puedes encontrar cómo se usan.
Te comenta tb lo del GBAK, pq nosotros en alguna ocasión para reparar una BD tuvimos que hacer copia de seguridad de los datos y luego volver a restauraros en un BD en blanco.
El tema de que estéis trabajando los tres al mismo tiempo no tiene nada que ver... sólo faltaría...

Si aun así teneís problemas para recuperarla, como último caso nosotros utilizábamos una herramienta llamada IBSurgeon; En su día era gratuíta, ahora no se si seguirá en el mismo estado (búscala por internet).

Dos cosillas más: La mayoría de nuestros errores (similares al vuestro) eran generados por cortes de luz y/o cuelgues del servidor (no se si ese puede haber sido vuestro caso). Otra cosa, es que podéis modificar un parámetro de Interbase (Forces writes) para que las escrituras se hagan de forma inmediata y no diferida. Baja el rendimiento, pero sube la estabilidad. Está bien explicado en ésta página:
http://delphi.buzzword.com/stories/s...4#ForcedWrites
(junto a otros parámetros...)

Suerte.

guillotmarc · #4 23-07-2004

Hola.

Cuando restauras una base de datos, no recuperas una copia exacta de lo que tenias en ese momento, sinó que reconstruyes la base de datos. Se vuelven a crear las tablas, índices, etc. ... Por lo que tras restaurar una base de datos, no debería poder tener errores. La corrupción de datos se produce posteriormente. (Así que en mi opninión no vale la pena pasar un gfix a la base de datos).

Estoy completamente de acuerdo en que los errores suelen provenir de cortes de luz, y que los Forced Writes deberian estar activados (en Firebird siempre están activados por defecto).

Saludos.

Neftali [Germán.Estévez] · #5 23-07-2004

Cita:

Empezado por guillotmarc

Cuando restauras una base de datos, no recuperas una copia exacta de lo que tenias en ese momento, sinó que reconstruyes la base de datos. Se vuelven a crear las tablas, índices, etc. ... Por lo que tras restaurar una base de datos, no debería poder tener errores.

Segun lo que comentas no es posible hacer una copia (backup) de una Base de Datos con errores y te puedo asegurar (por propia experiencia con clientes) que eso es posible con servidores de Interbase 6 (ya no se con posteriores y con FireBird), pero con IB "lo he sufrido en mis carnes..."

Dependiendo de las opciones que hayas seleccionado en el backup (sea visualmente o por línea de comandos -ig) se puede hacer una copia de seguridad de una Base de Datos con "páginas incorrectas". Habría que saber bajo qué opciones hizo la copia de seguridad.

Yo probaría lo siguiente:
(1) realizar un GFix de la BD recién restaurada.
(2) Para asegurarte de que la Base de datos a partir de un determinado punto es correcta y a partir de ahí empezar a diagnosticar errores; Haría un Backup/restore de la Base de Datos en dos partes; Por un lado los Metadatos y por otro (porsteriormente) los datos.

A partir de ese punto activa "forces Writes" y tal vez buscar una herramienta de LOG sobre el servidor que te ayude a detectar furturos problemas; Puedes probar IBLogManager (upScene) o alguna similar.

Un saludo.

guillotmarc · #6 23-07-2004

Hola.

Cita:

Empezado por Neftali

Segun lo que comentas no es posible hacer una copia (backup) de una Base de Datos con errores y te puedo asegurar (por propia experiencia con clientes) que eso es posible con servidores de Interbase 6 (ya no se con posteriores y con FireBird), pero con IB "lo he sufrido en mis carnes..."

¿ Donde he dicho esto ?. Yo también he sufrido este problema. Puedes hacer una copia de seguridad, sin saber que la base de datos está corrompida, y el gbak te puede decir que la copia ha finalizado correctamente (aunque lo más usual es que marque el error), con lo que te quedas tan tranquilo. Posteriormente cuando intentas restaurar esa copia, te puedes encontrar con que el gbak falla (pongamos por ejplo. porqué no puede regenerar dos registros con la misma clave primaria). Con lo que te encuentras que has borrado la base de datos original, y tienes una copia de seguridad que no puedes restaurar. Una situación muy divertida.

Yo lo que he dicho es que si la restauración finaliza con éxito, la base de datos que obtienes es totalmente coherente (puesto que proviene de un proceso de regenaración de los datos, y no de una copia de un archivo).

En mi opinión solo necesita mirar el GFix y las opciones del GBak si el proceso de Backup o el de Restauración le marca errores. En caso contrario (y por lo que dice, no tiene ningún error al restaurar la copia), debe centrarse en localizar el proceso que corrompe la base de datos. Puede ser, como comentas, el Forced Writes, una UDF defectuosa, un bug de Interbase 6 (tiene algunos en que los índices corrompen la base de datos), por ello es recomendable actualizar a Firebird (al menos a Firebird 1.0.3).

Saludos.

Gydba · #7 23-07-2004

Buenas,

Por casualidad estás utilizando campos blob?

Una prueba rápida que podrías hacer es bajarte la versión 1.5.1 de Firebird (dicen que las utilidades gback y gfix mejoraron, cosa que no pude comprobar), levantar la base allí y ver si te sigue fallando.

No me suena ni a un problema de los componentes, ni de concurrencia, obviamente la base se corrompe. De todas formas yo utilizo el IBExpert que me parece superior a la herramienta que mencionás, lo que no me queda claro es que es lo que se deconecta: si se cae el servicio de Interbase o el EMS... ¿?

Saludos