> >> So, with FW=OFF, killing server in-between can produce both orphan > >> nodes and missing entries depending on luck and parallel activity. > > > > True, but that is database corruption problem, not an order of precedence > issue. > > > > That is why using FW=OFF in a production environment (on any platform) is > just wrong! > > 1) This is not a corruption. Or, at least, this is a non-catastrofic > corruption that > the engine can deal with itself. It doesn't make the database unusable. > > 2) There's no much difference between FW ON and OFF in this particular > case. Even with forced writes enabled, the server may die in between writing > those pages.
I was referring to cases where the disk controller has ignored the engine careful write order, by "collapsing" disk sector writes and applying them in a sequence optimal for the disk but out of order from a FB perspective (Jim's comment about micro code optimization). In that case, the end result is a corrupted database. > 3) I respectfully disagree regarding FW=OFF for a [well controlled] production > environment. Although generally your point is surely valid. I understand, my concern is that the people who google for "best practices" will not appreciate the meaning of "well controlled". Further, under the heading "sh*t happens" even if a server is in an environment where no user can ever interact with it, it is possible that failure can result in a corrupt database unless FW=ON. Sean ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
