Re: Buffered log Vs. Unbuffered Log Database

From: "Neil Truby" <ntruby@netcomuk.co.uk> > >Obnoxio The Clown wrote in message <80gr4d$flt$1@news.xmission.com>... > > >May I stick my head out above the parapet on this one: in most cases, if >you > >do have some sort of failure that requires some sort of recovery or > >rollforward, you would probably do some sort of validation exercise to >see > >whether any data had been lost. I therefore feel that the extra >performance > >you get out of buffered logging justifies its use in most cases > >And what if you do have some sort of failure and rely upon automatic "fast" >recovery? My point is just that you're going to possibly lose any COMMIT records in the log buffer, and how many of those will there be? Most of the sites I've seen who have a crash have done some kind of audit to see whether they lost anything. In which case you would find any lost transactions. My perspective is that the performance benefit outweighs the potential small loss of resilience. One of the great myths here is that unbuffered logging guarantees commits aren't lost. But IMHO, there is always a (teensy-weensy little) chance that you can still lose a commit, even with unbuffered logging (due to latency), so you might as well get the performance benefits and keep your eyes open for the risk. If you blindly rely on fast recovery without a rollforward audit, you might as well rely on buffered logging with a rollforward audit. :-) If you can't do a rollforward audit, then you should stick to unbuffered logging, but otherwise I think buffered logging should at least be considered. I think it suffers from bad press. :-> $0.02 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com