Subject | Re: [ib-support] how to repair a damage backup ? |
---|---|
Author | Pete Clark |
Post date | 2003-01-14T22:25:08Z |
In message <002e01c2bbf9$ac3af130$9ac82cc8@Ricardo>, Ricardo Uzcategui
<ricardouven@...> writes
long, I will post it here.
Diagnosing and Repairing Database Corruption
Some kinds of database corruption can be repaired with InterBase
utilities such as gfixand gbak. However, a warning
should be given to the user that in some rare cases, a database file can
be corrupted beyond the ability of these tools
to repair the damage.
The most frequent cause of corruption is abrupt or catastrophic power
loss on the database server. This includes a
stand-alone Windows machine with a Local InterBase database. Shutting
off power when an application is in the
process of writing to a file (such as a database) can result in
erroneous or incomplete data being written to the file.
The database user should take every possible measure to prevent such
power loss.
Database corruption that can be repaired can most often be cleared up
with gfix. Always work on a copy of the
database, not the production database.
Use the OS to make a copy of the database. You must have exclusive
access to the database to do this.
$ cp atlas.gdb atlas_test.gdb
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 -f atlas_test.gdb
Mend database corruption. Only do this if the previous step reported
database corruption.
$ gfix -m -i atlas_test.gdb
Check to see if corruption was mended.
$ gfix -v -f atlas_test.gdb
If gfix still reports database corruption, we need to take further steps
to repair the database. The backup/restore
procedure will create a new database with no old record versions, no
page fragmentation, and newly-formed indices
and transaction log.
Back up database.
$ gbak -g -b -z -v atlas_test.gdb atlas.gbk
If there is corruption in record versions of a limbo transaction, then
you may need to include the -l switch to the above
gbak command to ignore limbo transactions.
Create new database from backup. This should create a pristine database,
with newly-made indices, no old record
versions, etc.
$ gbak -c -v -z atlas.gbk atlas_new.gdb
Check to see if new database is corrupt.
$ gfix -v -f atlas_new.gdb
--
Pete Clark
<ricardouven@...> writes
>Who know how to repair a damage interbase backup (gbk).I downloaded the file, but I can't remember where from! As it isn't too
long, I will post it here.
Diagnosing and Repairing Database Corruption
Some kinds of database corruption can be repaired with InterBase
utilities such as gfixand gbak. However, a warning
should be given to the user that in some rare cases, a database file can
be corrupted beyond the ability of these tools
to repair the damage.
The most frequent cause of corruption is abrupt or catastrophic power
loss on the database server. This includes a
stand-alone Windows machine with a Local InterBase database. Shutting
off power when an application is in the
process of writing to a file (such as a database) can result in
erroneous or incomplete data being written to the file.
The database user should take every possible measure to prevent such
power loss.
Database corruption that can be repaired can most often be cleared up
with gfix. Always work on a copy of the
database, not the production database.
Use the OS to make a copy of the database. You must have exclusive
access to the database to do this.
$ cp atlas.gdb atlas_test.gdb
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 -f atlas_test.gdb
Mend database corruption. Only do this if the previous step reported
database corruption.
$ gfix -m -i atlas_test.gdb
Check to see if corruption was mended.
$ gfix -v -f atlas_test.gdb
If gfix still reports database corruption, we need to take further steps
to repair the database. The backup/restore
procedure will create a new database with no old record versions, no
page fragmentation, and newly-formed indices
and transaction log.
Back up database.
$ gbak -g -b -z -v atlas_test.gdb atlas.gbk
If there is corruption in record versions of a limbo transaction, then
you may need to include the -l switch to the above
gbak command to ignore limbo transactions.
Create new database from backup. This should create a pristine database,
with newly-made indices, no old record
versions, etc.
$ gbak -c -v -z atlas.gbk atlas_new.gdb
Check to see if new database is corrupt.
$ gfix -v -f atlas_new.gdb
--
Pete Clark