On Sat, Sep 13, 2014 at 12:22 PM, Jan Flyborg jan.persson@... [firebird-support] <firebird-support@yahoogroups.com> wrote:

We have shipped Firebird Embedded bundled together with our product for a few years now and the system is currently in production at several thousand of our customer's sites...

All is well and Firebird has served us good so far with the exception of database corruptions that gets reported from a new set of customers every week..... We are now at the planning stage for the next major release of our product and we are thus rethinking if Firebird really is a good choice, because of this.

I can understand that. 

 

Lots of effort has gone into solving this problem on our side, so I think the normal prerequisites has already been put into place (e.g using forced writes and so forth), but our system needs to be up and running 24x7, which means that it is not possible to schedule periodic backup/restore cycles and my personal theory is that Firebird embedded gets corrupted over time if you are not doing this regularly.

Nice theory, but if the database is physically corrupt, you can't back it up, and if it's logically corrupt, you can't restore it.  I think it's worth looking elsewhere for the problem.

So I have have a few questions that I would appreciate if someone could answer:

1. Is it feasible to run Firebird Embedded 24x7 in a setup where there are no scheduled backup/restore cycles. If not, how often should this be performed to ensure that the database does not get corrupted.

It should be possible to run Firebird Embedded 24x7.  Without knowing what you're seeing as corruptions, it's very hard to guess why they're occurring.  What errors are your customers seeing?  What do they (and you) do to correct the errors? 

2. Most of our customers are not using a UPS. From my experiments I have not managed to create a corrupted database by turning of the power while doing a large set of writes (in a session running in VirtualBox). Could someone please confirm that this is indeed safe when you are running with synchronized writes turned on?

A hard shutdown should not corrupt a database that has forced writes enabled.  It might corrupt the file system, but again, without knowing what the errors and problem are, it's hard to guess. 

3. Are there any operations on a live database that should be avoided to minimize the risk of corruptions?

Dropping tables and altering tables to drop fields are pretty dangerous operations, but even if that is what's happening, the development group should be given a reproducible case that corrupts databases. 

4. Just read a discussion about whether it is needed or not to call fb_shutdown to stop Firebird Embedded. Could this be the reason why we are getting corruptions? Should we change our service to perform this call when it is stopped?

5. I have also seen discussions of turning of automatic sweeps of the database (and doing them manually instead). Is this a likely source of corruptions for our setup?

No. Sweeping the database is very much like backing it up without creating the backup file.  When a sweep starts during heavy database usage, it can reduce performance but not corrupt the database.

So, question back to you:  what errors are you seeing and how have you fixed them?

Good luck,

Ann