> This is a transcript of my gstat -h info:
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 26347849
> Page size 8192
> ODS version 11.1
> Oldest transaction 25545713
> Oldest active 26347481
> Oldest snapshot 26347481
> Next transaction 26347482
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 347
> Implementation ID 26
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Nov 18, 2010 1:49:26
> Attributes force write
>
> Variable header data:
> Database backup GUID: {D0FF9040-0002-47C9-B487-FC68B87751DF}
> Sweep interval: 0
> *END*
>
> Observe the large diff between "Oldest transaction" and all the other
> transaction numbers. This is a diff of over 800000 transactions!
>
> How should I "fix" this?
>
> When I extracted this info there were NO connections to it, it was
> completely idle.

This doesn't matter. Does running a sweep help?

The oldest (interesting) transaction (OIT) is the oldest transaction in
a different state than committed. As OAT was able to move forward, I
guess there was either a largish transaction, which was rolled back (and
the engine wasn't able to transform that into a commit) or you have a
stuck transaction in context of a distributed transaction aka 2PC.
Although, sweep isn't able to recover the latter.

Also keep in mind of various auto commit approaches in different
database access technologies, which basically maps to commit retaining,
thus keep the transaction context, which can be seen as not being
committed when it comes to the transaction counters above.

If you set the sweep interval to 0 (disabled), then run a scheduled
sweep e.g. every night as Karol has mentioned.


--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!