Hi



I did a backup/restore etc and it cleared it down nicely



But after 14 hours its back up to a gap of 27549



What would be a "good" gap, I assume anything around 1-100 or something
low heh



And how high would be bad enough to think about doing a backup/restore
again



This is obviously all fire fighting till we get to the root of the
issue, im trailing fb v2 atm too try and help figure out whats happening



Cheers

Andrew



From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
Sent: 13 October 2008 11:55
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] FB GBK and CPU Usage



Hello Andrew,

> 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

Your header statistics shows that you have a long-running transaction
somewhere producing a gap between OAT and NT of ~1.5 mio. A wonder that
the server is still alive.

To identify a long-running transaction with Firebird prior v2.1 can be
tricky, that said, you need to have your hands on the client application

source and know what it does regarding transaction management.

If you are in a heterogenous environment regarding access components
(e.g. BDE, IBX, IBO, ...) it even get worse.

The reason for slow DB performance during a backup with gbak usually is
due to garbage collection in the source database. This can be omitted
with the -g switch of gbak.

Anyway, you need to fix the transaction management in your client
applications, otherwise it's just a matter of time to get into
performance troubles again.

Identifying long-running transactions would be easy with Firebird 2.1
due to the monitoring tables. So, if you are able to upgrade your system

in a test environment to 2.1 this might be useful. Although, upgrading
the client application to 2.1 might result in upgrading the access
components as well ... You have to read the compatibility issues section

in the Firebird release notes.

You also could try our Firebird Transaction Statistic Logger utility to
e.g. spot a timestamp, where e.g. the gap between the transaction
counters drift away, although it won't tell you which transaction is
long-running.
http://blog.upscene.com/thomas/index.php?d=02&m=10&y=08&category=12

--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/



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]