FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
internal gds software consistency check (invalid block type encountered (147))
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 Código:
internal gds software consistency check... Código:
internal gds software consistency check... 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 |
#2
|
||||
|
||||
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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#3
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#4
|
||||
|
||||
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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#5
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#6
|
||||
|
||||
Hola.
Cita:
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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#7
|
|||
|
|||
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
__________________
Suerte .: Gydba :. |
|
|
|