Hello, > Thank you very much for your responses - this makes sense. We have a couple > of server side applications that run constantly. Although, they should all > be closing their connections. We will investigate further. > > Could this somehow be related to the .NET driver with connection pooling? The > one application that I suspect starts and commits small incremental > transactions, but uses connection pooling?
Don't know if Jiri is watching this group, but you might get better response to .NET provider related questions in the separate Firebird-net-provider support list. Beside that, as you are using Firebird 2.5, use the monitoring tables to detect the problematic client attachment. If you are interested in a continous stream of forthcoming operations, use the Trace API. With the Trace API you can have a look on what applications are doing and how. (Sorry for being a Trace API evangelist *g*) -- With regards, Thomas Steinmaurer http://www.upscene.com/ > Regards, > > --- In [email protected], Svein Erling Tysvær > <svein.erling.tysvaer@...> wrote: >> >>> I have 20+ databases in production, most of them between 3 and 8GB with no >>> BLOBs. My problem seems to be that >>> sweeping is not executing when I either perform a full backup or doing full >>> table scans. Below is the gstat >>> header info and as you can clearly see that it should have kicked in long >>> ago. We are running classic mode V2.5. >>> Can I see and output/error messages for sweeping? >>> >>> What are we overlooking? Our only current solution is to do a full backup >>> and restore at silly morning hours, >>> otherwise the system grows terribly slow due to garbage not being collected. >>> >>> Oldest transaction 460 >>> Oldest active 461 >>> Oldest snapshot 461 >>> Next transaction 50325450 >> >> You are overlooking that oldest transaction and oldest active transaction >> aren't moving. That means that Firebird must keep all changes done since >> transaction 460 or 461 started since old versions could still contain data >> visible to those old transactions. Another way to say this, is that you have >> one or more programs that do not take proper care of one or more >> transactions and this is the reason for your slowness. Sweeping could only >> sweep the first 460 records of your database, the rest cannot be swept until >> one or many of your transactions commit or rollback. >> >> Set >> > > > > > ------------------------------------ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Yahoo! Groups Links > > >
