>>Ann Harrison has - not too long ago - in this forum described how long
>>gone transactions still hold space in the database.

> ...which you didn't quite understand, methinks...while it's true
> that they have not restored their database for 20 months, that does
> not cause "27 million transactions to pile up". Transactions don't
> "pile up" and their system isn't "piling up" anything. Long-running
> transactions cause obsolete record versions to "pile up" (garbage,
> that is). But their application code is taking very good care of
> transactions, in fact these statistics are as close to "perfect" as
> I have ever seen in a production database.

Sorry if I gave a wrong recommendation, and thanks for the flowers,
Helen, but Ann usually is explaining such things in a way that even I
can understand them.

I understood that 27 million transactions mean 54 million bits set on
TIPs that could as well be removed from the database. I agree that
this is of course not a huge number of bits and that they don't occupy
much more than 3MByte in the DB; but garbage remains garbage, even if
your trashbin is big enough to keep a year's "output".

About the perfect-as-can-be statistics...
Here is one of mine, just snap-shot inmidst of production.

Flags 0
Checksum 12345
Generation 16656361
Page size 4096
ODS version 10.1
Oldest transaction 16656331
Oldest active 16656339
Oldest snapshot 16656339
Next transaction 16656340
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 3
Creation date Jul 25, 2008 15:59:25
Attributes force write

Variable header data:
Sweep interval: 20000


I honestly think that these statistics are looking quite good as well.
Nevertheless I know that the actual size of the db is 700+ MByte on
disk, while directly after a restore it will be ~125 MByte.

The statistics don't tell anything about what has been done during the
past 16 million transactions, how much space has been allocated and
such.

While the surplus of 575 MByte is far from being "huge" in FB database
terms, it nevertheless is a factor to keep in mind.
I know exactly from years of experience with this database that our
server will respond considerably faster again after I did a restore.

I also *think* that I understood from your and Ann's explanations that
this behaviour is quite normal, if you are doing a lot of deleting of
big tables, and don't fill them up again.

As long as the OP does not report what his database size is, and how
"fit" the server is in handling files of that size, a backup/restore
cycle is still what I would recommend; even if I only *think* I
understood you and Ann correctly, whithout actually succeeding in it
*g*

Thanks for being patient and trying over and over again.

ciao,
André