Subject Re: [firebird-support] Sweep isn't moving OIT
Author Ann Harrison


On Tue, Nov 26, 2019 at 3:26 PM lucasschatz@... [firebird-support] <firebird-support@yahoogroups.com> wrote:

I'm having a problem while running manually sweep, it's not increasing OIT as expected.

As you mentioned in your bug report, the problem was a transaction stuck in limbo - the first half of a
two-phase commit.  Sweep, quite rightly, doesn't clean up limbo transactions.  

Just to explain better:

I'm copying de DB as a backup, and I'm trying do sweep it, so I stopped Firebird, restarted, tried to sweep, stopped Fb again, tried to sweep with offline Fb server, tried gfix -mend, which found 3 warnings (0 fixed):

Sweep doesn't require stopping Firebird and stopping Firebird is going to have no effect on
the transaction that's half way through a two-phase commit. 


backup Thu Nov 14 18:27:53 2019
        Database: /db/db_no_sweep.fdb
        Validation started
        Warning: Relation has 2 orphan backversions {0 in use} in table CONTAS_A_RECEBER (247)
        Warning: Relation has 3 orphan backversions {0 in use} in table NFE_LOTE_DADOS (253)
        Warning: Relation has 8 orphan backversions {0 in use} in table NF_SAIDA_CAPA (575)

Orphan back versions waste space but have no effect on the consistency of the database.  They
are created if Firebird is stopped during garbage collection.  That shouldn't happen, but neither 
program or operating system crashes.  When the garbage collector - thread or cooperative - 
finds old versions of a record that are no longer needed by any active transaction it first sets
the back version pointer to zero in the oldest version of the record that is needed.  Then it
goes to the page that holds the back version and marks that space as free and available for
reuse.    


backup Thu Nov 14 18:53:44 2019
        Database: /db/db_no_sweep.fdb
        Validation finished: 0 errors, 3 warnings, 0 fixed 

I've got no error, no warning at all, any ideas?

As you suggest elsewhere, Sweep with a verbose mode might report that transaction xyzzy is stuck 
in the middle of a two-phase commit.  That would have saved you a lot of looking  

Good luck,

Ann