problemas con interbase

[carlomagno]

hola a todos

Tengo un pequeño problema
Hace unos dias hice una gran actualizacion que no se acaba nunca. La pare a saco y ahora cada dia tengo la base de datos corrupta. No se como arreglarla. En el log de interbase veo las paginas que se estropean pero no encuentro algun soft donde encontrar que registro me esta jodiendo.

Si a alguien le ha pasado lo mismo, por favor estoy desesperado.

Gracias

[hogol]

Prueba a hacer una copia de la base de datos y luego volver a restaurarla. En muchos casos con eso basta.

Saludos
Hogol

[carlomagno]

Si quieres decir backup/restore, lo tengo que hacer cada dia.
Y cada dia se me corrompe la BD.
Como puedo saber las paginas dentro de la BD?

[hogol]

A mi me pasó lo mismo hace unas semanas. Como no dices que error te da exactamente pues no se si será el mismo problema. En todo caso lo pude solucionar utilizando el ibconsole y la opción de validación, la cual busca errores en la base de datos y en caso de encontrar alguno te da la opción de repararlos.
En esta web lo explica todo paso a paso:
http://www.orologic.net/support/f14-en/10019-en.html

Suerte
Hogol

[angellvl]

Hola, espero que esto te sirva :
-----------------------------
Diagnosing and Repairing InterBase Database Corruption
Updated and revised 29th Sep 2000 by Paul Beach

A number of types and kinds of database corruption can be repaired with gfix (alice) and gbak (burp). However, it is possible in some rare cases that a database file may be corrupted beyond the ability of these tools to repair the damage. In such an instance more drastic measures may be needed to get the database back on line. If you try and repair your database and it fails, please contact us and we will see what we can do to help.

The most frequent cause of corruption is either an abrupt or catastrophic power loss on the database server. Shutting off the power when an application is in the process of writing to the database can result in corrupted or incomplete data being written to the database file. In all cases the database user, and database administrator should take every possible precaution to prevent this happening.

The InterBase Server has two write modes (forced writes), synchronous and asynchronous. Pre InterBase V6.0 the default write mode was synchronous:

gfix -write sync database.gdb
Post InterBase V6.0 the write mode is asynchronous:

gfix -write async database.gdb
Synchronous writes are known as "careful writes", in that the InterBase engine will flush modified pages to disk on a transaction commit, and will write the pages back to the database in the correct order (as far as the database server is concerned) and so minimise any possible data loss. Careful write is present in all cases, though without forced write, it's careful only up to the Operating System file cache. Forced write has no effect on Windows 3.1, Windows 95 and Windows 98. On Unix and NT, it causes the operating system to bypass its file cache and send the page directly to disk.

The normal mode on Unix systems has forced write off because it is a significant performance cost. The normal mode on NT is forced writes on because the Operating System is too flaky to trust with valuable pages. Prior to InterBase V6, all I/O was synchronous, meaning that when a page was read or written, the thread waited until the operating system said that the operation was done. That's a reasonable way to manage careful writes, in most cases, and it appears to be the way writes are done, in all cases. Asynchronous reads are new in InterBase V6 and allow the server to continue processing on behalf of a thread while the read is in progress. Unix systems don't support asynchronous I/O generally, so this is an NT only optimization. Careful writes are the way the world is. Forced writes can be turned off and on by the user. The server makes its own choices between synchronous and asynchronous I/O, never trading reliability for speed.

Typically most users turn forced writes off, for the performance gains that can be realised by letting the operating system synch its file cache automatically to disk when it needs to. If you are using asynchronous writes, carefully consider your backup strategy, just in case the worst happens.

The pre InterBase V6.0 Server Manager offered some database validation capabilities, as does IBConsole, however I would recommend using the command line gfix utility to repair database corruption, it has more options and flexibility.

Database corruption that can be repaired can most often be corrected either by gfix, or a combination of gfix and gbak.

1. Define the following two variables, it makes life easier, in that you do not have to type in the user name and password every time you issue a command.

SET ISC_USER=SYSDBA
SET ISC_PASSWORD=masterkey
2. Always make sure you work on a copy of the database, not the production database. Use the operating system to make a copy of the database. You must have exclusive access to the database to do this.

copy employee.gdb database.gdb
3. Now check for database corruption. You must have exclusive access to do this, but since you're working on a copy of the original database, this is not a problem.

gfix -v -full database.gdb
4. If the previous command has indicated that there are problems with the database, we now need to mend it.

gfix -mend -full -ignore database.gdb
5. Now check to see if the corruption has been repaired.

gfix -v -full database.gdb
6. If you still see errors, you should now do a full backup and restore. In its simplest format the backup command line should be:

gbak -backup -v -ignore database.gdb database.gbk
7. However if gbak falls over because it is having trouble with garbage collection, then use the following command:

gbak -backup -v -ignore -garbage
database.gdb database.gbk
8. If there is corruption in record versions of a limbo transaction, then you may need to include the -limbo switch:

gbak -backup -v -ignore -garbage -limbo
database.gdb database.gbk
9. Now create a new database from the backup:

gbak -create -v atlas.gbk atlas_new.gdb
10. If there are problems on the restore, consider using the following switches.

-inactive, if there are index problems, this will restore the database, but will not activate any indexes, you can then do this manually, one at a time.

-one_at_a_time, this will restore the database one table at a time, and commit the restored tables on each table restore, if there is a major problem, at least you can get some of the data back.

[angellvl]

La verdad q el documento es muy grande para pasarlo como post, si no te ha servido con eso pasame un email y te lo envio (es un .txt de 24kb aprox)

Un saludo

[carlomagno]

Gracias por vuestra ayuda.
El post lo veo bien, creo que esta completo.
Voy a probar con linea de comandos porque lo que hacia antes era backup restore y se me curaban todos los males. Pero solo temporalmente...

Gracias

[carlomagno]

Lo que no he dicho es que me da corrupta cuando la valido con la opcion "Validate Record Fragments = True"
y me devuelve

Summary of validation errors
Number of index page errors : 54

[jorge restrepo]

Hola me gustaria saber si ya resolviste el problema de la BD corrupta, ya que tengo el mismo y la inestabilidad de la BD es absurda ya que todos los dias hay que hacer copia, cuando se corrompe con el uso del gfix, el parametro garbage, etc. solo recupera algunos registros.. sera que tiene que ver con alguna configuracion en WIN2000...

[Casimiro Notevi]

seguramente está "arreglada" pero han quedado registros con claves que "apuntan" a otros, de otras tablas, que han sido eliminados en el proceso de reparación.