Hi,
Thanks again.
2014-09-14 19:56 GMT+02:00 Ann Harrison aharri...@ibphoenix.com
[firebird-support] <firebird-support@yahoogroups.com>:
>
>
> On Sat, Sep 13, 2014 at 12:22 PM, Jan Flyborg jan.pers...@gmail.com
> [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
