| Subject | Repeated database corruption |
|---|---|
| Author | esbreidenbach |
| Post date | 2009-08-05T16:42:16Z |
Hi to all,
We are encountering database corruption with only one of our
50 or so clients. I was able to recover the database most recently by using the gfix -mend command.
The client is currently using Firebird version 1.52.
The database is a back-end for a desktop application and a web site
built by us, and a third party application (read-only) which uses an ODBC connection. I would love to find out the cause of the corruption so I can prevent this from re-occuring.
The corruption has occured twice in the past year, and once two years ago.
In the most recent occurence, the first sign of something wrong according to the log file was this:
FS2 (Server) Tue Jul 21 00:19:47 2009
Database: D:\LABORPOWER\DATA\LPIBEW25.GDB
I/O error for file "D:\LABORPOWER\DATA\LPIBEW25.GDB"
Error while trying to read from file
The process cannot access the file because another process has locked a
portion of the file.
internal gds software consistency check (error during savepoint backout
(290))
The client was unable to login to the desktop application, and re-booted the database server. This solved the problem for them. They informed us and me and I did a backup/restore on the database without issue.
Ten days later, this log file entry coincides with the timing of our
automated nightly gbak backup script. The log file entry is:
FS2 (Server) Fri Jul 31 20:38:02 2009
Database: D:\LABORPOWER\DATA\LPIBEW25.GDB
internal gds software consistency check (wrong record length (183))
The client could not login to the application after re-booting the database server, so I was called and carried out the mend as mentioned. Thanks to the support group for instructions!
Questions:
1) We recently found out that the client was doing a nightly tape backup which includes the .gdb database file.
Could this be causing any the problems? The GDB file is now being
excluded from the backup, but I would like to be certain if this in fact was the cause.
2) If not, what else should I check.
3) After the gbak mend, the log file shows entries like these examples:
Relation has 3 orphan backversions (0 in use) in table MEMBER (128)
Record 10152 is wrong length in table WEB_USER (439)
Page 81771 is an orphan
Many of the last. Does this mean that I lost data? Can anyone explain
what these mean?
Thanks in advance,
Scott
We are encountering database corruption with only one of our
50 or so clients. I was able to recover the database most recently by using the gfix -mend command.
The client is currently using Firebird version 1.52.
The database is a back-end for a desktop application and a web site
built by us, and a third party application (read-only) which uses an ODBC connection. I would love to find out the cause of the corruption so I can prevent this from re-occuring.
The corruption has occured twice in the past year, and once two years ago.
In the most recent occurence, the first sign of something wrong according to the log file was this:
FS2 (Server) Tue Jul 21 00:19:47 2009
Database: D:\LABORPOWER\DATA\LPIBEW25.GDB
I/O error for file "D:\LABORPOWER\DATA\LPIBEW25.GDB"
Error while trying to read from file
The process cannot access the file because another process has locked a
portion of the file.
internal gds software consistency check (error during savepoint backout
(290))
The client was unable to login to the desktop application, and re-booted the database server. This solved the problem for them. They informed us and me and I did a backup/restore on the database without issue.
Ten days later, this log file entry coincides with the timing of our
automated nightly gbak backup script. The log file entry is:
FS2 (Server) Fri Jul 31 20:38:02 2009
Database: D:\LABORPOWER\DATA\LPIBEW25.GDB
internal gds software consistency check (wrong record length (183))
The client could not login to the application after re-booting the database server, so I was called and carried out the mend as mentioned. Thanks to the support group for instructions!
Questions:
1) We recently found out that the client was doing a nightly tape backup which includes the .gdb database file.
Could this be causing any the problems? The GDB file is now being
excluded from the backup, but I would like to be certain if this in fact was the cause.
2) If not, what else should I check.
3) After the gbak mend, the log file shows entries like these examples:
Relation has 3 orphan backversions (0 in use) in table MEMBER (128)
Record 10152 is wrong length in table WEB_USER (439)
Page 81771 is an orphan
Many of the last. Does this mean that I lost data? Can anyone explain
what these mean?
Thanks in advance,
Scott