Subject | Re: Corrupt database |
---|---|
Author | Adam |
Post date | 2007-09-20T23:43:20Z |
Hi Rob,
regular event on reliable hardware using a stable build of Firebird
and taking the recommended precautions and safe database file
management practices.
recovery can cause further damage, so it is essential you can 'go
back' if needed.
You mention the backup is failing, do you mean the backup process
fails or do you mean the backup process appears to succeed but you
can't restore the file?
Find out the output of gbak when it fails. If it is an index or
constraint, you may be able to simply drop it to make a successful backup.
Also (if you are lucky) gbak with -g option may work. It just depends
where the corruption is. Otherwise, you can try a data pump tool to
extract the good records.
My other suggestions relate to stressing the importance of validating
every backup of mission critical data and to make environmental
choices to minimise the chance of corruption (UPS / forced writes /
don't copy database files that are in use / exclude fdb file from
scanner paths).
Adam
> This morning the DB was corrupt, people got IO and 'internal GDS'errors
> trying log in. I don't have access to their system so I have triedAlarm bells should be ringing. Database corruption should not be a
> talking staff through the following process.
>
> Shut down FB server and restart.
> Copy DB to the fb\Bin dir
> Run Gfix -mend
> I got 17 record errors and 2 blob errors.
> Run GBak to create a backup of the db
> This failed
> (it has worked for me in the past)
regular event on reliable hardware using a stable build of Firebird
and taking the recommended precautions and safe database file
management practices.
> with some errorhave is
> (sorry staff not good at reporting errors). I will try and get it from
> them.
>
> so I
> Ran Gfix -mend again
> I got 13 record errors
>
> Re running Gfix -mend seems to always return the same number of errors.
> Running Gbak again failed with the same (?) error message.
>
> I tried Gfix -two_phase (Just ready to try anything)
> This returned no errors but a further gBak failed anyway.
>
> What are peoples other suggestions? The most recent backup they
> 2 days old. There backups have been failing and they have not noticed.Step 1: Burn the database file to a CD and lock it in a safe. Database
>
recovery can cause further damage, so it is essential you can 'go
back' if needed.
You mention the backup is failing, do you mean the backup process
fails or do you mean the backup process appears to succeed but you
can't restore the file?
Find out the output of gbak when it fails. If it is an index or
constraint, you may be able to simply drop it to make a successful backup.
Also (if you are lucky) gbak with -g option may work. It just depends
where the corruption is. Otherwise, you can try a data pump tool to
extract the good records.
My other suggestions relate to stressing the importance of validating
every backup of mission critical data and to make environmental
choices to minimise the chance of corruption (UPS / forced writes /
don't copy database files that are in use / exclude fdb file from
scanner paths).
Adam