******************************************** 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] >