Le 9 juin 2014 à 15:51, Mike Ro [email protected] [firebird-support] <[email protected]> a écrit :
> 3. Set the database mode to be asynchronous with: > > gfix -write async test.fdb -user sysdba -password secret It, of course, has a tremendous impact on such tests. Though, everybody should carefully consider wether the risks of data corruption are acceptable (or not) using sync writes off. I know most people here do know, but I wouldn't like you to get mislead by this recent topic. There are a large number of past discussions in this list archive about this very topic. May I recommend reading them even if not all do apply as severely to recent Firebird versions as older Interbase(R) editions. At the very least, to make it short, Firebird uses an ordered-writes technique to help preserve its on-disk structure in case of unexpected interruption. As soon as the OS is allowed to delay writes as it sees fit, that integrity security is lost. And the OS can go quite far in not following the initial order of the writes: plain-old common scatter-gather techniques can optimize the writes in such an unwanted way. So it is not just a matter of how much data may be lost by loosing computing resources right in the middle of some transactions, but how far the whole data is still meaningful after such an event, knowing that the ACID rules might have been broken by the OS re-ordering individual writes which did belong to various transactions. Careful backup plans or more advanced storage architectures (async DB on synced volumes exposed from heavily caching SAN subsystems, for instance) are required to overcome the risks of integrity loss. The path to follow depends on the amount of unavailability of data (during restoration) or data loss which is acceptable, and of course the amount of money available for implementation. On simple setups, using FB sync writes on SSD might be decent tradeoff between integrity assurance and speed. __ Olivier Mascia tipgroup.com/om
