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 guess its FB's way of dealing with it, rather than his? Not sure I
guess ill have to read up on it!





From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Alan McDonald
Sent: 13 October 2008 12:08
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] FB GBK and CPU Usage

> Hi All
> We are getting really slow DB performance during backups, we're a 24/7
> company and so cant run them during a down period.
> Gbak runs about 6-10% and FBServer runs a good 50% (dual core box so
> flat out on one core)
> After gbak has finished the fbserver is still running around 50%
> Is this normal?
> It's a windows 2003 box with fb 1.5
> I think the below isn't right, but im a total 'noob' when it comes to
> databases
> Any help would be greatly appreciated
> Cheers
> Andrew
> D:\Program Files\Firebird_1_5\bin>gstat -h e:\data\cabs.fdb
> Database "e:\data\cabs.fdb"
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 9959021
> Page size 4096
> ODS version 10.1
> Oldest transaction 8479679
> Oldest active 8479680
> Oldest snapshot 8378442
> Next transaction 9959010
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Jan 18, 2008 2:31:22
> Attributes force write
> Variable header data:
> Sweep interval: 20000
> *END*
>

These are the stats from one of my production DBs. Much more recently
restored after some log maintenance work so about 1 million less
transactions overall, but about 21K transactions per day compared with
your
36K transactions per day.
But the gap between my oldest active and next transaction is 4
the gap for you is approx 1.5 million.
(mine is also 24/7 20-30 users including replaction processes)
I'd say that underscores your problem.
A lot of transactions are being left uncommitted or unrolled back. This
certainly makes for a DB which slowly grinds to a snails pace. It's
trying
to manage all those back versions for all those transactions which it
thinks
are still active.
And the garbage collection job gets very difficult and time consuming
also.
Backups will be faster if you use -g switch which stops garbage
collection
taking place. But this is not a good long term solution for you IMO.
You need to sort out why those transactions aren't moving ahead.
Alan

Database header page information:
Flags 0
Checksum 12345
Generation 823167
Page size 8192
ODS version 10.1
Oldest transaction 799364
Oldest active 817236
Oldest snapshot 817236
Next transaction 817240
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Sep 5, 2008 18:03:54
Attributes force write



Head and Registered Office:
Call Assist Ltd,
Axis Court, North Station Road,
Colchester, Essex.
CO1 1UX
Telephone +44 (0)1206 771771
Fax +44 (0)1206 364268

Registered in England and Wales.
Registered Company Number 3668383
Authorised and regulated by the Financial Services Authority

Please Note : This electronic message contains information from Call Assist Ltd which may be privileged or confidential.
The information is intended for the use of the individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this information is prohibited.
If you are not the intended recipient please delete this email. If you have received this electronic
message in error, please notify us by telephone or email immediately.

Please consider the environment before printing this email.


[Non-text portions of this message have been removed]