| Subject | Re: [firebird-support] Firebird BUG |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-01-13T13:02:14Z |
At 12:08 PM 13/01/2006 +0000, you wrote:
internal gds software consistency check
This part is telling you that an operation was cancelled as a result of a
condition that occurred in the engine that has arisen earlier. Because the
engine can't resolve it, it cancels the entire operation where the
condition arose.
(error during savepoint backout (290))
And this is the condition that gave rise to the internal
inconsistency. AFAIR, it indicates that more than a maximum number (256?)
of updates are pending on the same record. It's never advisable to write
code that performs multiple updates on a record during the same
transaction: even 2 is one too many. In any case, it's unlikely to cause
corruption, since the cancellation of the operation will undo the offending
work. So your daily gfixes (mends?) aren't going to solve anything.
If I'm right about the usual cause of overflowing the savepoints limit, you
need to look for something in your application code, trigger code or a
stored procedure that is potentially going to pile up an exorbitant number
of update hits on a single record in a single transaction. Could be a
logic problem in a FOR loop that's trashing the undo log under certain
conditions; or some other form of infinite loop...
Are you able to reproduce the problem in your test environment? The trick
will be to find out from your customer just which operations most commonly
coincide with this message in the log.
And if this turns out to be a red herring, let's look forward to Ann H.
jumping in and putting her venerable finger on the right button. :-)
./heLen
>Hi,operation was cancelled
>
>since about a week I'm getting this error in 2 of 7 servers of one of
>our clients:
>
>Database: /manager/gdb/EcomaxUBR2000.GDB
>operation was cancelled
>internal gds software consistency check (error during savepoint
>backout (290))
>
>I've seached "the whole net" and found no answer to what may cause
>this. I'm using the following version of Firebird (on Fedora Core
>release 3 (Heidelberg)):
>
>gfix version LI-V1.5.2.4731 Firebird 1.5
>
>Any ideas what may be causing this? This is a 24x7 client and having
>to gfix the database daily is very problematic to us. Firebird gives
>me no hint on what may be causing it or where it is happening, so I
>can't work out the problem...
internal gds software consistency check
This part is telling you that an operation was cancelled as a result of a
condition that occurred in the engine that has arisen earlier. Because the
engine can't resolve it, it cancels the entire operation where the
condition arose.
(error during savepoint backout (290))
And this is the condition that gave rise to the internal
inconsistency. AFAIR, it indicates that more than a maximum number (256?)
of updates are pending on the same record. It's never advisable to write
code that performs multiple updates on a record during the same
transaction: even 2 is one too many. In any case, it's unlikely to cause
corruption, since the cancellation of the operation will undo the offending
work. So your daily gfixes (mends?) aren't going to solve anything.
If I'm right about the usual cause of overflowing the savepoints limit, you
need to look for something in your application code, trigger code or a
stored procedure that is potentially going to pile up an exorbitant number
of update hits on a single record in a single transaction. Could be a
logic problem in a FOR loop that's trashing the undo log under certain
conditions; or some other form of infinite loop...
Are you able to reproduce the problem in your test environment? The trick
will be to find out from your customer just which operations most commonly
coincide with this message in the log.
And if this turns out to be a red herring, let's look forward to Ann H.
jumping in and putting her venerable finger on the right button. :-)
./heLen