********************************************
We are using FB 2.5.1, but it happened with FB 2.5.0 as well, but I am not sure if the version made any difference.

These are the stats on the currently running database BKM8, and one I swept earlier BKM6 (BKM6 had the problem and the sweep took 4 hours).

It seems as if SWEEP is the answer.


Database "BKM8.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 239517
Page size 4096
ODS version 11.2
Oldest transaction 231261
Oldest active 231262
Oldest snapshot 186856
Next transaction 238866
Bumped transaction 1
Sequence number 0
Next attachment ID 645
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 18, 2012 22:36:49
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

and here is the one I did a sweep on (while it was connected to an application)

Database "BKM6_SAVE.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 449878
Page size 4096
ODS version 11.2
Oldest transaction 449080
Oldest active 449081
Oldest snapshot 449081
Next transaction 449085
Bumped transaction 1
Sequence number 0
Next attachment ID 786
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 2, 2012 17:09:05
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

--- In firebird-support@yahoogroups.com, Vander Clock Stephane <svanderclock@...> wrote:
>
> is it FB 2.5 or fb 2.5.1 ?
> because in 2.5.0 i also have this kind of problem on the index (corrupt
> all the time)
> the 2.5.1 now work like a charm :)
>
> try gfix if you have the time to see if the index are corrupted
>
> also commitretaining not so good ...
>
> On 1/30/2012 2:51 PM, Colin wrote:
> >
> > We have a 5GB Database FB2.5 Win2008 Server 4 Core M/C, 143 tables,
> > problem with table INV 48K Records
> >
> > When everyone logs off and then log on, access to INV is slow for the
> > last 7K Records. If we fetch all, it takes forever, but eventually can
> > log off and log on again and all is ok. Same is OK if we set all
> > indexes ACTIVE (takes 4 hours for this table), or do a backup. Also if
> > we sweep. this takes the same or more time.
> >
> > Questions:
> >
> > If we backup and restore the database is like new? data exported and
> > then reloaded into a copied schema? This seems to work.
> >
> > Can sweep occur if the database has connections, but no activity? If
> > it did, then we would not get all the sweep operations stacked up.
> >
> > Why does sweep (or the slow backup) take so long and if so, why is
> > there no cpu load? I would have thought that the CPU would have been busy.
> >
> > In the app - one transaction and all datasets/queries/procedures are
> > commitretaining.
> >
> > And, and why always this table - treated much the same as other tables.
> >
> > Are there special settings for the database connection? and how can we
> > know that this might happen (so we could backup and restore before the
> > last user logged out)?
> >
> > Lawrence
> >
> >
>
>
> [Non-text portions of this message have been removed]
>