Love your work!
Greg ________________________________ From: Michael B. Smith [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 11:38 AM To: MS-Exchange Admin Issues Subject: RE: Committing transaction logs In case anyone is interested, I expanded on this explanation a little bit, and added a discussion of checkpoint exhaustion, which I recommend you should be monitoring for on your Exchange server. <http://theessentialexchange.com/blogs/michael/archive/2008/04/28/ESE-Checkpoint-Depth.aspx> Regards, Michael B. Smith MCSE/Exchange MVP http://TheEssentialExchange.com From: Bob Peitzke [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 9:02 PM To: MS-Exchange Admin Issues Subject: RE: Committing transaction logs The specific case that got me thinking about this is a remote office E2K server with rather low disk space, on which the logs were accumulating in the mdbdata directory. The backup job had hung waiting for a tape the local person had not loaded, and there were an extra gig or so of log files. I just checked it again, and now it's back to normal level of free space and only a few log files. I didn't see any events in the applog other than an ESE 215 error that showed when I canceled the backup job, and the usual ESE 7xx events re. online defrags. Maybe I could turn up some logging to get more insight into tran log commitments? Thanks for this excellent explanation - I'm saving it. Have a nice weekend. - Bob ________________________________ From: Michael B. Smith [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 5:18 PM To: MS-Exchange Admin Issues Subject: RE: Committing transaction logs A concise explanation? Hrmmm. Well, first, doing a backup does NOT force logs to be committed. It means that the backup process waits until a checkpoint occurs, flushes the current transaction log, and during the backup additional checkpoints are not allowed to occur (that is, nothing is allowed to be flushed to the ESE database until after the backup is complete – leading to an increasing checkpoint depth, and in extreme situations, checkpoint exhaustion – but that is another discussion altogether). The ESE buffers are not flushed. So…data is written, in a serialized fashion, to the in-memory ESE cache and to the log buffers, as updates occur in an Exchange database. Logs are written to disk as logs fill up, or as checkpoints occur. (This may mean that a log can have nothing but a checkpoint record in it – but that is not the normal case.) In the ESE buffers, I/O is accumulated and prioritized by a process known as the “lazy writer”. The lazy writer scans the ESE buffers for dirty (modified) pages and builds an optimized list to flush those to disk. As that list is flushed to disk, the pages are marked as “clean”, and the checkpoint is marked as having advanced (on a transaction by transaction basis, not a log by log basis). Whenever the transaction in a log are fully advanced, then the checkpoint file and the database header are updated. During a backup, the lazy writer is paused. The ONLY time you are assured that logs are fully committed is during clean shutdown, or after running soft recovery. So…what is the problem you are trying to address or question you are trying to answer? I might be of more help if I know that. Regards, Michael B. Smith MCSE/Exchange MVP http://TheEssentialExchange.com From: Bob Peitzke [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 6:24 PM To: MS-Exchange Admin Issues Subject: Committing transaction logs I'm looking for a concise explanation of when/how the transaction logs are committed. Specifically, is there another way to force logs to be committed other than the backup or stopping the IS? (E2K3) TIA Bob Peitzke ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
