Steffen,

> Remember that Windows itself has an option to use direct writes in the
> device configuration. If you have an UPS attached, you should disable that
> option, it will speed up your server.
> On one server of ours, (that was a dc with active directory), writing speed
> changed from about 2mb/s to about 80mb/s. (Actually that effect was not
> reached by a "usual" UPS , but by adding a battery pack to the raid controller
> itself, but this is about the same source.)

A UPS and a battery for a disk controller is NOT the same thing.

UPS protection DOES NOT allow for the "write back" feature of Windows to be activated (disable direct writes). It is VERY POSSIBLE to corrupt a disk by disabling direct writes, unless a cache battery is present.

> 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.
> Therefor if a system is that severely broken, forced writes only slightly
> reduce the problem (by reducing the amount of time that data remains in
> the output buffers), but you will not have a safe database either (because
> the data was in memory a lot longer before being modified and written
> back).
>
> Instead of enabling forced writes in this case, you should repair your
> system.

Fixing the system won't help if you have lost data due to an abnormal system termination.

> > 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...

A faulty system is not what Forced Writes is designed to solve


Sean