Subject | internal gds software consistency check (error during savepoint b ackout (290)) |
---|---|
Author | Ignacio J. Ortega |
Post date | 2003-01-14T10:51:24Z |
Firebird 1.0.0.796, w2k advanced server sp3 with all latest patches.
Not a vry buig gdb, only 5 to 10 users online, with w2k professional
clientns, all with the exact same version of the client..
I'm getting the error below [1] in interbase.log from time to time ( 1
time every 2 weeks or so ), this error occurs during the normal
operation of our system, blocking any further operation against the gdb,
the gdb gots corrupted, giving the second error [2] below and forcing us
to reparation and fixing with gfix of the gdb, that remains slow until a
complete BAckup/restore cycle is done..
My questions are:
a) what [1] means?
b) which can be the cause?
c) can i do something to alleviate it?
d) where in fb sources is [1] emited?
I didnt a compelte forensics of the problem, as i'm unable to reproduce
it in house, and when ocurred was a non controlled way..
ANy advices will be appreciatted... at least where to look at in the FB
code.. to try to fix the problem myself..:)
Saludos,
Ignacio J. Ortega
1)-------------------------
SERVER-GR1 (Server) Tue Jan 14 11:02:28 2003
Database: d:\data\production.gdb
lock conflict on no wait transaction
deadlock
operation was cancelled
internal gds software consistency check (error during savepoint
backout (290))
--------------------------
2)--------------------------
SERVER-GR1 (Server) Tue Jan 14 11:27:15 2003
Database: d:\data\production.gdb
internal gds software consistency check (wrong record length
(183))
--------------------------
Saludos,
Ignacio J. Ortega
Not a vry buig gdb, only 5 to 10 users online, with w2k professional
clientns, all with the exact same version of the client..
I'm getting the error below [1] in interbase.log from time to time ( 1
time every 2 weeks or so ), this error occurs during the normal
operation of our system, blocking any further operation against the gdb,
the gdb gots corrupted, giving the second error [2] below and forcing us
to reparation and fixing with gfix of the gdb, that remains slow until a
complete BAckup/restore cycle is done..
My questions are:
a) what [1] means?
b) which can be the cause?
c) can i do something to alleviate it?
d) where in fb sources is [1] emited?
I didnt a compelte forensics of the problem, as i'm unable to reproduce
it in house, and when ocurred was a non controlled way..
ANy advices will be appreciatted... at least where to look at in the FB
code.. to try to fix the problem myself..:)
Saludos,
Ignacio J. Ortega
1)-------------------------
SERVER-GR1 (Server) Tue Jan 14 11:02:28 2003
Database: d:\data\production.gdb
lock conflict on no wait transaction
deadlock
operation was cancelled
internal gds software consistency check (error during savepoint
backout (290))
--------------------------
2)--------------------------
SERVER-GR1 (Server) Tue Jan 14 11:27:15 2003
Database: d:\data\production.gdb
internal gds software consistency check (wrong record length
(183))
--------------------------
Saludos,
Ignacio J. Ortega