Re: [firebird-support] CORE-4467
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' s...@broadviewsoftware.com [firebird-support] : > > > > > 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 > > >
RE: [firebird-support] CORE-4467
> 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
Re: [firebird-support] CORE-4467
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). 2014-06-21 0:02 GMT+03:00 Jesus Garcia jeg...@gmail.com [firebird-support] < firebird-support@yahoogroups.com>: > > > > > El 20/06/2014, a las 21:33, "Ivan Arabadzhiev intelru...@yahoo.com > [firebird-support]" escribió: > > > > So I was redirected to the list to discuss > http://tracker.firebirdsql.org/browse/CORE-4467. > > What I can add is that it occurred to me to run a validation on the > database after I get the error (I keep a copy, just in case backup/restore > goes wrong). > Result is : > Summary of validation errors > > Number of record level errors : 3 > Number of database page errors : 1 > > Given that backup/restore goes smoothly, I assume the errors are in > metadata pages (somewhere in index if the error is anything to go by). > I`m willing to run any suggested tests that might help. The load that > breaks the database is reproducable but I`d really prefer not to upload a > few years worth of customer data (worst case scenario - I`ll scramble it > and take the chance). > As I said before - up to about a month ago things have been running fine. > > >
Re: [firebird-support] CORE-4467
> El 20/06/2014, a las 21:33, "Ivan Arabadzhiev intelru...@yahoo.com > [firebird-support]" escribió: > > So I was redirected to the list to discuss > http://tracker.firebirdsql.org/browse/CORE-4467. > > What I can add is that it occurred to me to run a validation on the database > after I get the error (I keep a copy, just in case backup/restore goes wrong). > Result is : > Summary of validation errors > > Number of record level errors : 3 > Number of database page errors : 1 > > Given that backup/restore goes smoothly, I assume the errors are in metadata > pages (somewhere in index if the error is anything to go by). > I`m willing to run any suggested tests that might help. The load that breaks > the database is reproducable but I`d really prefer not to upload a few years > worth of customer data (worst case scenario - I`ll scramble it and take the > chance). > As I said before - up to about a month ago things have been running fine. >
RE: [firebird-support] CORE-4467
> So I was redirected to the list to > discuss http://tracker.firebirdsql.org/browse/CORE-4467. In the case you indicate that you are using a trigger to calculate the statistics for all indexes. Why are you doing this from a trigger? (instead of running a script on a scheduled basis) > Result is : > Summary of validation errors > > Number of record level errors : 3 > Number of database page errors : 1 Not entirely sure what these errors mean on their own. Are there entries in the firebird.log file? Sean
[firebird-support] CORE-4467
So I was redirected to the list to discuss http://tracker.firebirdsql.org/browse/CORE-4467. What I can add is that it occurred to me to run a validation on the database after I get the error (I keep a copy, just in case backup/restore goes wrong). Result is : Summary of validation errors Number of record level errors : 3 Number of database page errors : 1 Given that backup/restore goes smoothly, I assume the errors are in metadata pages (somewhere in index if the error is anything to go by). I`m willing to run any suggested tests that might help. The load that breaks the database is reproducable but I`d really prefer not to upload a few years worth of customer data (worst case scenario - I`ll scramble it and take the chance). As I said before - up to about a month ago things have been running fine.
