Hi Jan,
You did not tell what kind of corruption you had (please provide full
text of error). There are plenty of them, as well as reasons.
You also could use our tool FirstAID (Direct) to analyze database on low
level and see where are the problems.
Regards,
Alexey Kovyazin
IBSurgeon (www.ib-aid.com)
Hi,
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. Currently we are using
Firebird Embedded 2.5.1 with the latest .NET-driver and a stack
consisting of Castle Active Record on top on NHibernate and the system
is running on the latest versions of Windows.
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. For some of them it is possible to instruct the customer
on how to repair the databases themselves, but some of the databases
are unfortunately so heavily corrupted that they need to be sent to us
for repairing (which is a tedious work that steals time from other
tasks). Most of them corruptions are normally found in the tables that
gets the most writes, but I guess that is only natural.
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.
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.
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.
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?
3. Are there any operations on a live database that should be avoided
to minimize the risk of corruptions?
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?
Thanks in advance. Maybe are there no certain answers to my questions,
but any pointers in the right direction would be very appreciated.
Firebird has been a real workhorse for us and we would rather like to
keep it.
Best Regards
//Jan Flyborg
