> I've notice that my so called uncommited transaction is growing very fast.
> The way I calculated this is by substacting the "Oldest Transaction" from
> the "Oldest Active" form the gstat -h output. How to go about this?Any
> pointer is much appreciated.

Fix the transaction handling in your application.

Somewhere, uncommitted transactions are lying around.

Rule of thumb:
- keep transactions as short as possible.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

> When the difference gets to hundreds of millions the db will be very slow

in

> processing requests. At this point I need to do a backup restore.

Currently

> I need to do this at least twice a month. I've just do a backup restore
> yesterday and look at the difference between "Oldest Transaction" and
> "Oldest Active"
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 3645883
> Page size 8192
> ODS version 10.1
> Oldest transaction 2600080
> Oldest active 2623121
> Oldest snapshot 2600081
> Next transaction 3645871
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 19
> Shadow count 0
> Page buffers 4000
> Next header page 0
> Database dialect 3
> Creation date Oct 4, 2006 18:26:40
> Attributes force write
>
> Variable header data:
> Sweep interval: 0
> *END*
>
> If it matters the application that uses this db is a web base java
> application.