Re: regarding concept of physical logging??

Of course, physical logging becomes close to unused in 9.2 + except in special situations, which of course makes everything clearer :) Will In article <3a81e8e5$1@news.iprimus.com.au>, "Andrew Hamm" <ahamm@sanderson.net.au> wrote: > Mark D. Stock wrote in message <95sktn$s2m$1@news.xmission.com>... > > > >The disk may "be havin the old data", as you put it, but it may also "be > >havin some old and some new data". The fast recovery process ensures a > >consistent set of data. > > > And the final magic in the chain of events is: > > After the disk has been reverted to old data by restoring from the physical > log, (here comes the magic) the logical logs are "replayed" and it takes the > data forward to the time of the crash. Finally, any uncommitted transactions > AT THAT IMAGINARY TIME are rolled back, and therefore you have the database > recovered to the point in time of the crash. > > The completeness of the logical log rollforward depends on whether you are > using buffered or unbuffered logging for a database. If logging is buffered > then the smallish log records for that database are not flushed to disk > quite as often as for an unlogged database. Fortunately, this is less of a > problem on a busy engine, because there is so much traffic that even with > unlogged databases the logical log buffer gets flushed fairly often. > > Choice of buffered (oops, nearly wrote a naughty word) vs. unbuffered > logging depends on how important it is for you to NOT lose a single > committed transaction. With our systems generally the users can check their > latest document in the system so it's not really an issue. > > Now you understand the role of the physical log? It's all very clever stuff. > > Sent via Deja.com http://www.deja.com/