Subject | AW: [firebird-support] Firebird RAID Windows Server 2008 R2 |
---|---|
Author | Steffen Heil |
Post date | 2010-12-05T12:28:22Z |
Hi
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.)
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.
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...
Regards,
Steffen
[Non-text portions of this message have been removed]
> > Is the possible unreliability on Windows only applicable in theseRemember that Windows itself has an option to use direct writes in the
> > cases (power loss/abnormal windows shutdown/freeze)?
> >
> > In that case async mode is acceptable, because we run a UPS.
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.)
> That only protects you against power losses. But with forced writes off,your
> mutations 'hang' in memory until the OS decides that it's time to writethem
> to disk. It may be seconds, minutes or more - you simply don't know. Foras
> long as the changes have not been written to disk, the situation is'unsafe'.
> Power losses and abnormal shutdowns are rather dramatic examples, butI strongly disagree.
> other things can go wrong too - with the buffer, with the scheduler - and
> cause failures, in the worst case without you even noticing it.
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.
> So the advice is always: for any serious use, don't turn off forcedwrites,
> except *temporarily* e.g. during mass data imports. After such an event,This is also unrealistic. IF you have a problem that affects your system
> check that everything has gone well.
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...
Regards,
Steffen
[Non-text portions of this message have been removed]