I am now on-site rebuilding the database, with a little time to
clarify issues. Obviously I need to keep this system up regardless of
what happens in the future. I only posted the original message because
I firmly believe I have a rock solid argument regarding corruption.

Yes I wasn't happy with the Nbackup problem but it didn't cause
corruption.

However this time the message in Firebird.log was;
internal gds software consistency check (wrong record length (183),
file: vio.cpp line: 1109

I can confidently eliminate hardware as the cause of my problems as I
have used 4 different servers since 2.0. Each has had problems.

Likewise I have used a number of different Linux distributions. The
only possible issue here is that I am using 64 bit machines now.
Tonight I am running up a 32 bit linux to see if that is more stable.


You wrote;
"> ..in *your* production environment...right? Firebird databases
don't corrupt in a "serious production environment" but it sounds as
if you are over a barrel now and it's too late for you to approach
(with us) what is happening in *your* environment to cause this
corruption."

Of course you are wrong.

Perhaps if you read my example, which is typical of the problems I
have had ever since Version 2.0 you will understand the design flaw.
Put another way;
A corrupt Firebird database is able to accept data until a process
like gbak accesses it and causes the gds consistency error.
I know this to be true because I have restored numbers of Nbackup
copies that also have the corruption. These Nbackup files were made
hours before the first sign of the gds error.
Today I needed IB surgeon to recover the corrupted database to a point
where I could recover the missing data. That was a 5 hour process.
I am sure you understand how serious that becomes when 50 users need a
database.
This data then needs to be examined and reentered into the restore of
a known good backup. That process usually takes me about 2 hours and
only then because I have written the SQL necessary to identify and
update changed data.

Consider this as a strong recommendation for an enhancement.
An external log would enable a database to be restored at the speed of
the merge function - probably minutes.

My current backup strategy involves restoring backups as soon as they
are complete onto another machine so that should a problem arise I can
immediately switch over. That strategy is optimum if I have hardware
failure but useless if I am missing 14 hours of data. Even with
Nbackup running hourly I stand to lose an hour of data.

I would be most grateful if someone can tell me how I can run a
Firebird system with no lost data upon corruption without such a log.

IBLogManager looks interesting. I will download a trial but it appears
to store its data in the same database. That is no solution to the
problem.

I appreciate the help here but as you can see I don't need help in
this situation.

I have built a very competitive system for this company using open
source software and remain committed to the same. Unfortunately my
client doesn't see things the same way and I can't say I blame them.

Michael Boyle.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 01:19 PM 24/06/2008, you wrote:
> >I think I have finally lost the will to argue the case for Firebird.
> >Repeated database corruption has cost my major client thousands of
> >dollars in downtime.
> >
> >I have done everything possible;
> >gbak & restore, correct client software etc. but every month or so the
> >dreaded
> >"internal gds software consistency check (can't continue after
> >bugcheck)" message returns.
>
> So this is a different site from the one you described a few days
ago, when questioning what was going on with nbackup in v.2.1?
>
> << The LVM routine was established during V2.0. use of the database(s).
> Although this database corrupted (gds inconsistency error) on average
> every three months under 2.0 (never under 1.5) >>
>
> >Of course the architecture of Firebird buries database corruption
> >where it becomes costly to find e.g.
> >
> >Data corrupts at 9 am, next gbak is 23:30 pm. Corruption is discovered
> >during nightly gbak which fails. Database from night before needs to
> >be restored and entire day's data salvaged from corrupt database (if
> >possible).
> >Nbackup is useless as it just copies the problem.
> >
> >The only workaround is to manually log data into a separate database.
> >
> >This is a design fault so significant I could not recommend Firebird
> >for use in a serious production environment.
>
> ..in *your* production environment...right? Firebird databases
don't corrupt in a "serious production environment" but it sounds as
if you are over a barrel now and it's too late for you to approach
(with us) what is happening in *your* environment to cause this
corruption.
>
>
> >Firebird needs an external transaction logging system that allows
> >reentry of data from last gbak session somewhat along the lines of a
> >concurrent delta file but record based not page based. That would
> >provide a useful restore function.
>
> Firebird doesn't need an external transaction logging system, but if
*you* do, then there is IBLogManager (Google it).
>
> On Linux, Forced Writes doesn't work prior to v.2.1, so that's one
safeguard you didn't have with v.1.5 and v.2.0.3 and below, if Linux
was your platform.
>
> >If I sound bitter it is because I have to get on a flight in 2 hours
> >to discuss the implementation of MS SQL Server - something that I
> >never wanted to do and a decision that was taken out of my hands.
>
> Well, I you're on the way to the airport now and we (and you) have
seem to have missed the opportunity to discover what has been causing
your corruptions...or even what kind of corruptions they were...but
it's there to be found, somewhere.
>
> And, yeah, I can relate to your grief - not least the grief that
awaits you with your new DB engine. Good luck with it.
>
> ./heLen
>