Well, when I say "recently" I actually mean that it happened 3 times this month (bad weather). Perhaps I should`ve mentioned that I noticed the exact same error two more times in the last year. Apparently only some of the workstations were active at the time and they just retried till there was no longer an issue. My guess is I simply got lucky and it broke pages that were not needed while still active.
About 3 months ago the machine went from 16 to 24 GB RAM but there seem to be absolutely no other side effects - dmesg is clean, regular gbaks go just fine. The box doesn`t really do anything besides the database and backups. I am generally a keeping an eye on it, since I`ve lost a huge amount of sleep on that exact database. It cracks under this very specific case when one station does massive updating (recalculates few thousand rows in 2-3 tables) and there are lock conflicts in the mean time. There are cases when I can coordinate the sync manually (it`s not needed often, happens only when the internet is down for more than a day or two at a site) - if I let it happen 'in peace' (does the same updating but there are almost no conflicts with other stations trying to write to the database), it goes OK. In fact that`s mostly where I feel the extra RAM - used to be totally impossible to let it happen during work hours, because it held records for too long. Also, every Sunday I run a SP on the database which sometimes grows the database by up to 1GB (not related to firebird, there are some errors in the tables with ~30M records which I need to 'heal') - always goes ok but there are no other active connections at the time. I know it`s somewhat of a strange db design and I`ve tried to push optimizations (many of them unsuccessfully). I`ve came to terms with it taking time. What bothers me is it raising a bugcheck. I`m have the disk space to restore a test db and put it in the same conditions. Not sure what test would help diagnose it though. 2014-06-21 1:17 GMT+03:00 'Leyne, Sean' [email protected] [firebird-support] <[email protected]>: > > > > > Index recalculation (I think) was done to minimize the configuration > needed > > (unfortunately, I wasn`t involved in the initial design). Non the less - > it hasn`t > > been an issue for the past 7-8 years and is still working in most > instances. > > The error count comes from a full validation with gfix (done on a file > "broken" > > by the issue I`ve described in the core). > > If the problem is a recent one, have you considered a hardware problem? Or > some other infrasturce change which could explain the 'sudden' issue? > > > Sean > > >
