Subject | [firebird-support]Index corruption |
---|---|
Author | Paul |
Post date | 2009-04-07T09:36:51Z |
We have experienced out first database corruption from any of our customers
in 15 years of Interbase and Firebird!
I would like some clues as to what may have caused it.
FB 1.5.3, windows server 2003, superserver
The databases appeared to backup without problem. On restore they would
fall over with 'string truncation . . . ' error on 2 foreign keys and
violation of not null constraint on a primary index. Dropping and replacing
the indexes didn't fix it and there where no null values in the table with
the primary key problem.
I forgot about GFIX having never had to use it before so I have no idea if
it would have helped.
I was able to fix the databases by backing up, restoring with 'deactivate
indexes' and 'don't enforce validity conditions', then running a small
program to activate the indices one at a time. When it reached a bad one it
reported it so I could then remove it and use the program again until all
good ones where active. I then reinstated the removed indexes and was able
to backup and restore normally.
At first I thought this might have caused by ill advised windows copying of
the live database files which may have been locking mid way through index
pages ( quite prepared to admit I could be talking rubbish here ) but the
strange thing is that there are 2 databases with identical structures and
different data. However since one primary key and 2 foreign keys where
commonly corrupted in both databases it seems a less likely candidate (and I
have no evidence copying happens anyway).
Another thought was updating database structures using the scripts created
by ib_expert database comparer. However one of the indexes corrupted in
both databases hasn't been changed for many years. Whether this could have
been cross contaminated by something else I have no idea. There is no
access to files for the virus checker, there has been no messing with system
tables (other than a few tricks in the database comparer script) and there
is plenty of spare disk space.
Any idea what could have happened to the indexes?
Would GFIX have made the fix easier?
Best regards
Paul
[Non-text portions of this message have been removed]
in 15 years of Interbase and Firebird!
I would like some clues as to what may have caused it.
FB 1.5.3, windows server 2003, superserver
The databases appeared to backup without problem. On restore they would
fall over with 'string truncation . . . ' error on 2 foreign keys and
violation of not null constraint on a primary index. Dropping and replacing
the indexes didn't fix it and there where no null values in the table with
the primary key problem.
I forgot about GFIX having never had to use it before so I have no idea if
it would have helped.
I was able to fix the databases by backing up, restoring with 'deactivate
indexes' and 'don't enforce validity conditions', then running a small
program to activate the indices one at a time. When it reached a bad one it
reported it so I could then remove it and use the program again until all
good ones where active. I then reinstated the removed indexes and was able
to backup and restore normally.
At first I thought this might have caused by ill advised windows copying of
the live database files which may have been locking mid way through index
pages ( quite prepared to admit I could be talking rubbish here ) but the
strange thing is that there are 2 databases with identical structures and
different data. However since one primary key and 2 foreign keys where
commonly corrupted in both databases it seems a less likely candidate (and I
have no evidence copying happens anyway).
Another thought was updating database structures using the scripts created
by ib_expert database comparer. However one of the indexes corrupted in
both databases hasn't been changed for many years. Whether this could have
been cross contaminated by something else I have no idea. There is no
access to files for the virus checker, there has been no messing with system
tables (other than a few tricks in the database comparer script) and there
is plenty of spare disk space.
Any idea what could have happened to the indexes?
Would GFIX have made the fix easier?
Best regards
Paul
[Non-text portions of this message have been removed]