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

StartKill · #8 26-07-2004

Gracias por su interes, les comento que he analizado cada uno de sus comentarios y hemos tomado el siguiente plan;
He restaurado la base,
Hemos validaddo no encontrando errores,
Se ha cambiado de servidor fisico,
Se cambio el Interbase 6.0.1 po la Interbase 6.0.2.0

y si continuara los errores tendremos s que revisar nuestro programa ya que como alguien comento: se esta haciendo algun proceso que corrompe la bdd

Se despide, your friend

StartKill
Lima-Peru

StartKill · #9 26-07-2004

Hola, nuevamente aqui presente...

Bueno, como en mi mensaje anterior especifique las medidas que tome, pero aun persisten los errores:

Despues de generar un script con el IB-Expert (structura y datos), procedi a crear una nueva base de datos... he hice un copia de seguridad (con un simple copy CTRL+C..CTRL+V) "por seguridad baje el ibserver antes de copiar"

Ninguno de los programadores toco la base de datos mas solo uno (el que suscribe) y empeze a crear con el "ib-expert" y el "ems" tablas, indices, clave foraneas sin mayores problemas.

Cuando todo ya me parecia al 100% SIN ERROR, se me ocurrio crear un generador con el "EMS" y zass un error

Cita:

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

"oh my god!!!" es el EMS me dije, procedi a restaurar la copya "por seguridad baje el ibserver antes de restaurar"

y volvi a generar otro generador en el IB-EXPERT y volvio caer..

Consultando con mis compañeros en que momento creen que sucedia el problema de "desconexion" atinaro en decirme en la generacion de generadores...

Espero que lo explicado pueda dar una pista a solucionar este problema, ademas pego un pedazo del log:

Código:

INFORMATICA05 (Client)	Mon Jul 26 12:26:44 2004
	Guardian starting: C:\Archivos de programa\Borland\InterBase\bin\ibserver.exe


INFORMATICA05 (Server)	Mon Jul 26 12:27:20 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

INFORMATICA05 (Server)	Mon Jul 26 12:31:28 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

INFORMATICA05 (Server)	Mon Jul 26 12:31:44 2004
	INET/inet_error: read errno = 10054

INFORMATICA05 (Client)	Mon Jul 26 12:31:47 2004
	C:\Archivos de programa\Borland\InterBase\bin\ibserver.exe: normal shutdown


INFORMATICA05 (Client)	Mon Jul 26 12:32:19 2004
	Guardian starting: C:\Archivos de programa\Borland\InterBase\bin\ibserver.exe


INFORMATICA05 (Server)	Mon Jul 26 12:39:14 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

INFORMATICA05 (Server)	Mon Jul 26 12:40:20 2004
	Database: C:\DB_DEL~1\CENTRAL\SMATXX.GDB
	internal gds software consistency check (invalid block type encountered (147))

GyDba me pregunto si utilizaba campos blob, pos amigo no los utilizamos.

Se depide su amigo,

StartKill
Lima-Perú

jachguate · #10 26-07-2004

Te has planteado utilizar firebird. La migración es prácticamente transparente... y probablemente deje de ocurrirte esto, que por cierto me parece mas que extraño, ya que durante unos años use interbase, y jamás vi algo parecido.

Hasta luego.

larcomar · #11 26-07-2004

Hola, he creado una base de datos sin datos, solo su structura, tablas, indices, trigers..

Estoy utilizando el ib-expert, cuando creo genradores se desconecta la base de datos... he vuelto a crear otra vez la bdd sin procedures ni trigers, he vuelto a intentan añadir otro genrator y vuelve desconecarse,

Ahora, vuelvo a crear la bdd sin procedures, no trigers, no generator... y empiezo a crear mis generators y lo hace perfectamente...

Pregunta: existe alguna regla para la creacion de generadores ya que pienso que alguno de los generadores que existen tiene algun "defecto"

Con respecto a pasarme a firebird, es escuchado/leido: que los componentes IBX no aprovecharian el 100% del base de datos FB y ademas que los componentes IBX no son 100% compatibles lo que me pudiera surgir algun error inesperado. Decirte que que tengo algunos programas con componentes IBX y mi temor es hacer este cambio por lo mencionado..(cambiar uno a uno mis componentes , propiedades, eventos..)

Bueno amigos...

Your friend,

StartKill
Lima-Perú

Nota: Por error me sente en la PC de mi compañero y este message esta con su nick..bye, bye

StartKill · #12 26-07-2004

Se me olvidaba, este es el error de ib-expert...

Código:

Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
internal gds software consistency check (invalid block type encountered (147)).

Your friend,

StartKill
Lima-Perú

jachguate · #13 26-07-2004

Cita:

Empezado por larcomar

Pregunta: existe alguna regla para la creacion de generadores ya que pienso que alguno de los generadores que existen tiene algun "defecto"

Ninguna que yo conozca que al no ser cumplida corrompa la BD.

Cita:

Empezado por larcomar

Con respecto a pasarme a firebird, es escuchado/leido: que los componentes IBX no aprovecharian el 100% del base de datos FB y ademas que los componentes IBX no son 100% compatibles lo que me pudiera surgir algun error inesperado.

Pues habrá que ver que dicen los expertos... pero yo no he tenido problamas al pasar unas cuantas BD's de ib 6.01 a Firebird 1.5. El problema de incompatibilidad entre IBX y firebird, vendrá en el futuro. Por ahora son dos productos tan parecidos, a nivel de API, que IBX ni se da cuenta del cambio...

Claro que vale la pena plantearse el asunto desde ya... de cualquier forma, si queres conservar tus sistemas con IBX, será mejor que vayas desembolsando lo necesario para pasarte a Interbase 7, o por lo menos al 6.5. Si no, pues que comences desde ya a planear tu futuro al lado de firebird.

Hasta luego.