Subject | GDS/Error |
---|---|
Author | Rodrigo Gonçalves |
Post date | 2004-05-17T12:35:12Z |
Hi,
in one of our clients the following errors ocurred in the last friday( I
got this from the Firebird log):
(Server) Mon May 10 13:13:20 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
Soon after the following errors ocurred too:
(Server) Fri May 14 14:37:57 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
(Server) Fri May 14 14:39:00 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
(Server) Fri May 14 15:18:09 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Index 15 is corrupt (missing entries) in table CL_PACIENTES (215)
(Server) Fri May 14 15:18:43 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Relation has 1 orphan backversions (1264 in use) in table
CL_ATENDIMENTOS (266)
(Server) Fri May 14 15:18:44 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Index 8 is corrupt (missing entries) in table CL_CONSULTAS (267)
(Server) Fri May 14 15:18:44 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Page 216647 is an orphan
The system was running the Firebird 1.5 RC6. I've followed the Changelog
for Firebird but found nothing regarding if something that could
originate this error was fixed. Anyway, I've recommended changing the
the FB 1.5 Final release.
My question is, what could originate this errors? I assure the system
wasn't uncleanly shutdown and the hardware is OK. May the fact that the
clients are using IBX and some still use BDE (some for long running
transactions) cause this? Also I've found out that clients even used the
IB client libraries instead of the the FB one. I recommended the changes
too.
Analysing the database, I've found that the oldest transaction (not the
oldest active) was very, very far from the next transaction
(1108,1535038). Could this also originate the problem?
What I could say I fear is how a system that was running nicely for 2
months (with very large activity) could present such problems "from
nothing"? If they were originated by bad clients, how come the server
doesn't validate against this?
Also a backup/restore of the database was done 2 weeks ago.
Tks for any help/tips
Rodrigo
in one of our clients the following errors ocurred in the last friday( I
got this from the Firebird log):
(Server) Mon May 10 13:13:20 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
Soon after the following errors ocurred too:
(Server) Fri May 14 14:37:57 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
(Server) Fri May 14 14:39:00 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
internal gds software consistency check (wrong record length (183))
(Server) Fri May 14 15:18:09 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Index 15 is corrupt (missing entries) in table CL_PACIENTES (215)
(Server) Fri May 14 15:18:43 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Relation has 1 orphan backversions (1264 in use) in table
CL_ATENDIMENTOS (266)
(Server) Fri May 14 15:18:44 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Index 8 is corrupt (missing entries) in table CL_CONSULTAS (267)
(Server) Fri May 14 15:18:44 2004
Database: /manager/gdb/EcomaxUBR2000.GDB
Page 216647 is an orphan
The system was running the Firebird 1.5 RC6. I've followed the Changelog
for Firebird but found nothing regarding if something that could
originate this error was fixed. Anyway, I've recommended changing the
the FB 1.5 Final release.
My question is, what could originate this errors? I assure the system
wasn't uncleanly shutdown and the hardware is OK. May the fact that the
clients are using IBX and some still use BDE (some for long running
transactions) cause this? Also I've found out that clients even used the
IB client libraries instead of the the FB one. I recommended the changes
too.
Analysing the database, I've found that the oldest transaction (not the
oldest active) was very, very far from the next transaction
(1108,1535038). Could this also originate the problem?
What I could say I fear is how a system that was running nicely for 2
months (with very large activity) could present such problems "from
nothing"? If they were originated by bad clients, how come the server
doesn't validate against this?
Also a backup/restore of the database was done 2 weeks ago.
Tks for any help/tips
Rodrigo