| Subject | Re: [IBO] Record In Limbo ... what's it mean? |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-03-03T01:25:03Z |
At 11:15 AM 3/03/2009, you wrote:
Never resolve a limbo transaction by dropping the table! Limbo status is perfectly "normal" where you have two-phase (multi-database) transactions on an unstable network. So the preventive medicine is to refrain from using two-phase transactions on a network that allows connections to drop arbitrarily - or fix the cause of the dropouts. (The cause for such events is waaaaay off-topic, something you need to figure out with your network admin. Or it might just be as simple as telling the site users not to switch off their servers when replication is running!)
You get limbo transactions when a multi-database transaction fails to complete its second-phase step of flagging the multi-database transaction as committed (or rolled back). It is due *always* to a loss of connection to one of the databases at that phase. To fix all the databases affected, you need to get that transaction ID out of limbo in all them. The tool is gfix. You need to be SYSDBA to do it. If you have The Firebird Book, you'll find the instructions in Ch. 39, starting at page 848. If not, you should get enough info from the Borland OpGuide.pdf, downloadable via the IBPhoenix site.
Helen
>This problem cropped up with a user DB. We're running Firebird 2.1,Yes: although this is NOT an IBO question.
>with an application written in Delphi, using IBObjects as the interface.
>
>A table in the user's database (it's a temp table that we empty and
>fill at program startup) began throwing an error with the following:
>
>ISC_ERROR_CODE: 335544459
>ISC_ERROR_MESSAGE: "record from transaction 690824 is stuck in limbo".
>
>To try to figure things out, I went into Database Workbench, and got
>the same error message (same transaction # also) any time I tried to
>view the data or run an SQL against the table. I was finally able to
>clear things by dropping and re-creating the table.
>
>NOW ... my REAL question ... if this happens again, is there any
>facility, either within the Firebird native tools, or in DB Workbench,
>that I can use to clear the hung record and restore a table to
>functionality? Preferably without loss of other data...???
Never resolve a limbo transaction by dropping the table! Limbo status is perfectly "normal" where you have two-phase (multi-database) transactions on an unstable network. So the preventive medicine is to refrain from using two-phase transactions on a network that allows connections to drop arbitrarily - or fix the cause of the dropouts. (The cause for such events is waaaaay off-topic, something you need to figure out with your network admin. Or it might just be as simple as telling the site users not to switch off their servers when replication is running!)
You get limbo transactions when a multi-database transaction fails to complete its second-phase step of flagging the multi-database transaction as committed (or rolled back). It is due *always* to a loss of connection to one of the databases at that phase. To fix all the databases affected, you need to get that transaction ID out of limbo in all them. The tool is gfix. You need to be SYSDBA to do it. If you have The Firebird Book, you'll find the instructions in Ch. 39, starting at page 848. If not, you should get enough info from the Borland OpGuide.pdf, downloadable via the IBPhoenix site.
Helen