Subject Re: Controlling expansion of database file / grow-by option?
Author Svein Erling Tysvær
Hi David!

I don't know about sweeping (I only do development, Aage is our DBA
and I need Helen's book even to do a backup/restore), but autocommit
is a problem (speedwise, the result is identical to a long-running
transaction). It does ensure that data won't be rolled back, but it
doesn't allow the oldest active transaction to move forward. The
result is that your database grows because it has to store every
version of every record. If you have a small database with few
updates, then you're fine, otherwise your queries gradually become
slower until your database becomes useless.

Longer transactions will not solve anything, they should contain one
logical unit of work and finish with a hard commit (well, if you have
a batch job with lots of updates, you could commit every 10000 records
or so). Only use autocommit if you know that you will do a hard commit
shortly (I hardly ever use autocommit). Don't forget that even SELECTs
have to be committed regularly.

The positive side of this is that once you replace your autocommits
with hard commits, then you - and the users - will be far more
satisfied with Firebird.

Set

--- In firebird-support@yahoogroups.com, David Vasconcelos wrote:
> We don't have many long running operations... but our application
> autocommits almost everything. We have a lot of situations where the
> database file is huge compared to the backup file.
>
> Sounds like we should change our app to make longer transactions.
>
> In the meantime, should we consider more frequent sweeping?
>
> Thanks!
>
> David