Excellent - thans you Michael On 4/28/08, Michael B. Smith <[EMAIL PROTECTED]> wrote: > > > > 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 > > 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 ~
