Hi!
The short-term solution would be (as already said):
- disable all access to the database (use gfix -shut, disable network, or use a
firewall)
- Backup: "gbak -G server:database.fdb backup.fbk -user x -pass y"
- Restore: "gbak -C backup.fbk server:database_new.fdb -user x -pass y"
- Rename
- enable all access to the database

The long-term solution:
If you are using Firebird>=2.1 you could use the various MON$ Tables to find out
why your transactions are stuck.

good luck!
Michael

-----Ursprüngliche Nachricht-----
Von: Andrew Stuart
Gesendet: 13.10.2008 13:33

> Hi
>
>
>
> Whats the quickest way to reset the difference, ie correct it, as a one
> off for the time being?
>
>
>
> Restart FB service and Sweep ?
>
>
>
> Need minimum downtime
>
>
>
> Cheers
>
> Andrew
>
>
>
> From: firebird-support@yahoogroups.com
> [mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
> Steinmaurer
> Sent: 13 October 2008 12:28
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] FB GBK and CPU Usage
>
>
>
>> Thanks all so far, we're lookin at running with -g during the day and
> a
>> garbage enabled one at midnight
>>
>>
>>
>> However talking to our developer he's not convinced hes' using
>> transactions?
>
> I'm afraid, I can of worm then, because the access components are
> therefore responsible for doing the transaction stuff, thus leading to
> problems like using CommitRetaining when using some kind of AutoCommit.
>
> It's very important to understand Firebird transactions and how to use
> them with the access components correctly.
>