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

 

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.

Yes you are correct. I can see that now.

 

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? 

I just made another posting where I tried to describe three different examples of things we have seen. It would be really nice if you could take a look at this.

 

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. 

As explained in a previous post, we never do that with other transactions running.

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?

Typically we fix our problems with a gfix -mend and then doing a backup restore cycle. Usually some tables then still have problems (typically foreign keys that refers to non existing primary keys), so if possible we then remove the faulty records and then it works again.

However, some database are so heavily corrupted that this strategy would give us an empty database and if that is the case we have to tell the customer to start all over again again with an empty file.

Best Regards

    //Jan Flyborg