Steffen Heil wrote:

>> Power losses and abnormal shutdowns are rather dramatic examples, but
>> other things can go wrong too - with the buffer, with the scheduler -
>> and cause failures, in the worst case without you even noticing it.
>
> I strongly disagree.
>
> Surely there are things that can go wrong with schedulers and buffers.
> But these are severe system failures that might also affect any other
> information in the memory, such as firebirds internal buffers and more.

Might or might not. I'm not claiming that forced writes are a panacea
for all kinds of system failures. But they do reduce the risk of 'saved'
changes remaining in volatile memory during a time that isn't under your
control, and possibly (though with a very low probability) not being
written at all, or incompletely.

It's a safety precaution. The fact that other things still may go wrong
doesn't mean it's not useful. I would only turn off forced writes if
speed was of the utmost importance.

>> So the advice is always: for any serious use, don't turn off forced
>> writes, except *temporarily* e.g. during mass data imports. After
>> such an event, check that everything has gone well.
>
> This is also unrealistic. IF you have a problem that affects your
> system this way, you have no reliable way to tell if everything worked
> well. The database cannot tell, if you wanted to write a 0 or 1...

Depending on the importance of the data, you might do anything from
just checking the number of inserted/deleted/updated rows, through
checking the last *n* changes, to verifying each and every change
against the import source. Of course you can do this with or without
forced writes on. With forced writes on (i.e. turned back on after the
import), at least you know that all the changes are really on disk.


Paul Vinkenoog