At 05:01 PM 11-09-02 +0200, you wrote:

> > > > What is the information regarding the transactions that is returned by
> > >GSTAT?
> > > Generation 92098
> > > Oldest transaction 77749
> > > Oldest active 77750
> > > Oldest snapshot 77724
> > > Next transaction 92088
> > I that the difference between Oldest Active and Next Transaction is
> > wide. Usually, a backup and restore brings them closer.
>the problem is that this database does about 200000 transactions a day. i
>have investigated this problem further and i found out that the transactions
>are moving for some time and then suddendly stop moving. when the difference
>between the oldest and the next trx becomes too great the problem arises.
>restarting the server from time works but it can't stay this way. what could
>cause the trx numbers not to move forward?

An application that
(1) selects a set and holds it open all day
(2) uses CommitRetaining and never hard-commits the transaction
(3) crashes with a bunch of uncommitted work

An environment where
(1) DDL is performed on a database while users are active
(2) users run a lot of apps simultaneously and keep uncommitted work lying
around hidden in task-bar icons
(3) auto sweeping is disabled and nobody runs manual sweeps
(4) gbak is rarely or never run
(5) users "log out" by hitting the "off" switch
(6) a reporting app is running huge reports to an overloaded printer queue

Still 'n' all, lack of OIT movement shouldn't affect CPU usage, even though
it will eventually kill the server.
Is your server XP and by chance an unknowing victim of SystemRestore or
some other background Microsoft invention targeted at gdb files?
Are you sure ibserver is eating the whole pie?

heLen