Subject | Re: [firebird-support] Transaction Pointer Question |
---|---|
Author | Ann W. Harrison |
Post date | 2009-08-31T15:39:45Z |
ck1625 wrote:
values is with a sweep. The "oldest transaction" is the first
transaction that made changes and did not commit. It's over and done
with (normally) and stable until sweep guarantees that any changes it
may have made are gone.
The cost of having a very old "oldest transaction" is that Firebird must
check the state of all subsequent transactions before accepting that
record versions created by them are committed. That check is done with
a bit vector and the age of the "oldest transaction" determines the size
of the bit vector. For a modern superserver version of Firebird, the
size of that vector is probably irrelevant. For classic, where each
connection has a separate vector, its size might be interesting. Back
in the early 1980's when the mechanism and sweeping were invented, the
size of the vector could be significant.
So, no, there's no cheaper way to change the oldest active, but no,
it's not performance critical. If you use gbak for regular backups,
you might just run a sweep after the backup when it will be reasonably
quick.
Good Luck,
Ann
Cheers,
> Hi,The only way (short of backup/restore) to change the oldest transaction
>
> again I have a problem with my database. The "Oldest transaction" is not updated:
>
>...
> ODS version 11.1
> Oldest transaction 66388302
> Oldest active 66873045
> Oldest snapshot 66873045
> Next transaction 66883806
> ...
>
>
> Not even stopping all applications that use the database help. I suppose
> when I do a sweep it helps, but this always slows down the database for
> several hours.
>
> Is there no other way to fix it? And how bad is it, if the value is not moving?
>
values is with a sweep. The "oldest transaction" is the first
transaction that made changes and did not commit. It's over and done
with (normally) and stable until sweep guarantees that any changes it
may have made are gone.
The cost of having a very old "oldest transaction" is that Firebird must
check the state of all subsequent transactions before accepting that
record versions created by them are committed. That check is done with
a bit vector and the age of the "oldest transaction" determines the size
of the bit vector. For a modern superserver version of Firebird, the
size of that vector is probably irrelevant. For classic, where each
connection has a separate vector, its size might be interesting. Back
in the early 1980's when the mechanism and sweeping were invented, the
size of the vector could be significant.
So, no, there's no cheaper way to change the oldest active, but no,
it's not performance critical. If you use gbak for regular backups,
you might just run a sweep after the backup when it will be reasonably
quick.
Good Luck,
Ann
Cheers,