Subject | FB2.0 amd64 Nbackup and corruption |
---|---|
Author | mb_at_ss |
Post date | 2006-12-03T21:27:57Z |
Hello.
I have been using Firebird / IB since it went open source.
My database is currently about 9-10 GB stored in one file and probably
manages between 10000 and 100000 transactions per day for around 40-50
users. About 100 tables about 300 stored procedures.
Obviously with that many transactions even an hour's lost data is a
serious problem.
After about 5 years with only one serious incident I upgraded to FB 2.0.
It has not gone well. In four weeks we have had four corruptions
ranging from a completely unusable database to blob corruption.
These have happened on both an i686 multi processor machine and an
amd64 single processor machine both running the appropriate version of
SUSE 10.1 Linux.
The only reason we are running at the moment is that I hastily wrote a
trigger based replication system to continuously duplicate all the
data changes onto another server.
Each time the corruption has first been noticed during the operation
of Nbackup which has failed leaving a delta file. In all but one
occasion the delta merged successfully but a subsequent GBAK failed.
An additional problem during the conversion was that the RFUNC UDF
does not work and will not compile on SUSE. I can get it to compile on
a Debian machine but it still refuses to work.
This forced me to replace all the references to RFUNC with other
stored procedures using the standard UDF and a bit of extra work.
Now to the questions.
Is there a specification on processor requirements for the different
versions of FB? Not all 64 bit processors are equal.
What version of Linux is FB 2 compiled on? I will install that if it
helps.
Is there any documentation on how Nbackup knows what data has changed?
It might be a more efficient way to manage the replication than three
triggers on each table.
I am avoiding a return to 1.5 because I don't want to have to do the
work twice.
Thanks in advance for for any advice.
I have been using Firebird / IB since it went open source.
My database is currently about 9-10 GB stored in one file and probably
manages between 10000 and 100000 transactions per day for around 40-50
users. About 100 tables about 300 stored procedures.
Obviously with that many transactions even an hour's lost data is a
serious problem.
After about 5 years with only one serious incident I upgraded to FB 2.0.
It has not gone well. In four weeks we have had four corruptions
ranging from a completely unusable database to blob corruption.
These have happened on both an i686 multi processor machine and an
amd64 single processor machine both running the appropriate version of
SUSE 10.1 Linux.
The only reason we are running at the moment is that I hastily wrote a
trigger based replication system to continuously duplicate all the
data changes onto another server.
Each time the corruption has first been noticed during the operation
of Nbackup which has failed leaving a delta file. In all but one
occasion the delta merged successfully but a subsequent GBAK failed.
An additional problem during the conversion was that the RFUNC UDF
does not work and will not compile on SUSE. I can get it to compile on
a Debian machine but it still refuses to work.
This forced me to replace all the references to RFUNC with other
stored procedures using the standard UDF and a bit of extra work.
Now to the questions.
Is there a specification on processor requirements for the different
versions of FB? Not all 64 bit processors are equal.
What version of Linux is FB 2 compiled on? I will install that if it
helps.
Is there any documentation on how Nbackup knows what data has changed?
It might be a more efficient way to manage the replication than three
triggers on each table.
I am avoiding a return to 1.5 because I don't want to have to do the
work twice.
Thanks in advance for for any advice.