Subject | Database corruption |
---|---|
Author | Adam |
Post date | 2008-10-29T05:13:35Z |
Hello Group,
I had a report from a customer about a corrupt database, and I am
looking for any hints to determine what has actually occurred and
(hopefully) what may have caused it.
Win 2003 Server, 1.5.5 Classic, from firebird.log:
SERVER Tue Oct 28 14:30:04 2008
Database: E:\DATA\DATA.FDB
database file appears corrupt ()
wrong page type
page 195537 is of wrong type (expected 7, found 5)
internal gds software consistency check (error during savepoint
backout (290))
This error occurs hundreds of times as different connections have hit
the corrupt page and crashed.
I have resolved the immediate issue with gfix mend, then a
backup-restore cycle, but I need to, to the extent possible, get to
find the cause.
This particular customer hosts their own database, so my control over
there environment is limited.
I have subsequently removed a share on the E drive which could have
exposed the fdb to some tool (like XCopy or some antivirus), and have
insisted that they test the RAM. My next step (should this happen
again) would be to use the ACLs to disallow access at the file system
level to the fdb.
So presuming I can be confident that no-one is accessing the fdb
directly, and that the RAM is not faulty, what else can I look at?
TIA
Adam
I had a report from a customer about a corrupt database, and I am
looking for any hints to determine what has actually occurred and
(hopefully) what may have caused it.
Win 2003 Server, 1.5.5 Classic, from firebird.log:
SERVER Tue Oct 28 14:30:04 2008
Database: E:\DATA\DATA.FDB
database file appears corrupt ()
wrong page type
page 195537 is of wrong type (expected 7, found 5)
internal gds software consistency check (error during savepoint
backout (290))
This error occurs hundreds of times as different connections have hit
the corrupt page and crashed.
I have resolved the immediate issue with gfix mend, then a
backup-restore cycle, but I need to, to the extent possible, get to
find the cause.
This particular customer hosts their own database, so my control over
there environment is limited.
I have subsequently removed a share on the E drive which could have
exposed the fdb to some tool (like XCopy or some antivirus), and have
insisted that they test the RAM. My next step (should this happen
again) would be to use the ACLs to disallow access at the file system
level to the fdb.
So presuming I can be confident that no-one is accessing the fdb
directly, and that the RAM is not faulty, what else can I look at?
TIA
Adam