fabiano_bonin wrote:

> [root@servidor firebird]# gfix -list ./thal02.fdb.old
> Transaction 54335 is in limbo.
> Could not reattach to database for transaction 54335.
> Original path: 200.216.111.199:thal02
> Enter a valid path:
>
> It makes some years i'm working with many FB servers, and it's the
> first time i had this problem. I'd like to know what can cause it and
> how i can solve.

My guess is that you had two databases connected when a network error
occurred, or one of the servers crashed at a very bad moment. When you
commit a multi-database transaction, the system automatically drops into
a two phase commit. The first phase on each database forces all
necessary changes to the data and metadata to disk, writes a record in
RDB$TRANSACTIONS explaining who it is, how to find its partners, and the
transaction ids of the shared transactions on the partner systems. The
last part of the first phase writes out the transaction inventory page
marking the transaction as 'limbo'. When that completes, the first
phase returns. When all partners say that they've completed the first
phase, they're all told to go start the second phase which consists of a
single write that marks the transaction as committed and removing the
record from RDB$TRANSACTIONS.

When something goes wrong between the time any partner sets its state to
prepared and all partners commit, you get remnants of a two-phase
commit. The information you're seeing tells you how to find the state
of the partner transactions. If any one of them is rolled back,
everybody rolls back. Otherwise, everybody commits. If you care about
consistency. Otherwise, it's every partner for itself.

The short answer to your query is to check the documentation in gfix,
which allows you to attach to a limbo translation and tell it to commit
or die.

Regards,


Ann