Subject Re: RE: [firebird-support] fb statistic
Author xuxu
Martin Dew
I find the description about that in opguide.pdf of IB 5.6 (May be there are some differences between IB and FB about this).

Page 181:
-----------------------------------------------------------------------------------------------------
Oldest transaction: the transaction ID number of the oldest “interesting” transaction
(those that are not committed, but active, in limbo, or rolled back).
Oldest active: the transaction ID number of the oldest active transaction.
Next transaction: the transaction ID number that InterBase assigns to the next
transaction.

Note **The difference between the oldest transaction and the next transaction ** determines
when database sweeping occurs. For example, if the difference is greater than this
difference (set to 20,000 by default), then InterBase initiates a database sweep.
-----------------------------------------------------------------------------------------------------

Page 138:
---------------------------------------------------------------------------------------------------------
AUTOMATIC HOUSEKEEPING
If a transaction is left in an active (unresolved) state, this is an “interesting” transaction.
In a given database’s transaction inventory, the first transaction with a state other than
committed is known as the Oldest Interesting Transaction (OIT). If a client starts a new
transaction and the transaction number is greater than a certain threshold past the
number of the OIT, the InterBase server initiates a full sweep of the database. By default,
this threshold is 20,000 transactions, and is configurable (see “Setting the sweep
interval” on page 139).
Note It is a subtle but important distinction that the automatic sweep does not
necessarily occur every 20,000 transactions. It is only when the difference between the
OIT and the newest transaction reaches the threshold. If every transaction to the database
is committed promptly, then this difference it is not likely to be great enough to trigger
the automatic sweep.
The InterBase server process initiates a special thread to perform this sweep
asynchronously, so that the client process can continue functioning, unaffected by the
amount of work done by the sweep.



======= 2004-12-22 09:36:00 =======

>If my understanding is correct then the sweep interval if set to let's say 20,000 would then wait for a gap of this amount between the oldest transaction and the oldest active transaction, once this gap is reached between these two counters then it would fire a sweep.
>
>If you set a sweep to 0 it will never fire a sweep, you will always have to manually fire one off.
>
>I think the only way you are going to get the transactions in line is a backup and restore, but more importantly you need to find out where your transaction is being held open, as this is what is causing your gap.
>
>I hope I have informed you correctly, if not I am sure someone will correct this reply.
>
>Martin Dew
>
>
>-----Original Message-----
>From: xuxu [mailto:xufh@...]
>Sent: 22 December 2004 09:29
>To: firebird-support@yahoogroups.com
>Subject: [firebird-support] fb statistic
>
>
>firebird-suppor
>
> The usage of cpu of my FB always grows up to 99 . Here is the statistic of my FB .I have set the sweep interval
> to 0 .but the difference between the next transaction and the oldest active transaction is very large.
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 1662925
> Page size 4096
> ODS version 10.1
> Oldest transaction 1636503
> Oldest active 1636504
> Oldest snapshot 1615008
> Next transaction 1662909
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 19
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Jun 4, 2004 9:44:42
> Attributes
>
> Variable header data:
> Sweep interval: 0
> *END*
>
>
>
>
>        xuxu
>        xufh@...
>          2004-12-22
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

= = = = = = = = = = = = = = = = = = = =


        致
礼!


        xuxu
        xufh@...
          2004-12-22