Hello All We are running Exchange 2007 (CCR) on Windows 2008 Server. The other day, we experienced an issue where we almost ran out of space on one of our log drives. We had to carry out a dismount, move the logs via Ex Management Console to a another location, and then remount. This raises some questions for us...based on the article here: http://www.msexchange.org/articles/Exchange-log-disk-full.html Questions: 1. Let's say we encounter the same problem again. We're not sure if a backup will finish before the space runs out. Is there any way to find out which logs have been commited and which not? The article mentions running ESEUtil /mk to interrogate the CHK file, however this can only be done when the DB is down, correct? 2. If we do dismount the store and run /mk, I'm still confused as to how we know which files have been commited and which not (the article doesn't really go into that!). Example, on my test machine, I have dismounted the store and the value is: Checkpoint: (0x53, 8, 16). I understand that I'm only interested in the 0x53, but how do I convert this into a log file? And is it anything before (and including) that log file I can move? 3. When Exchange dismounts a store gracefully, aren't ALL log files for that store commited(assuming 1:1 relationship between store and SG)? In which case, we could move all the log files? 4. Would failing over to the passive CCR node help at all? 5. Is there anyway that the Toolbox (I'm thinking Database Recovery Toolset) can move the commited logs either before or after dismounting? Thanks for any help!

On Thu, 30 Dec 2010 19:08:20 +0000, Chuck_P2101 wrote: >We are running Exchange 2007 (CCR) on Windows 2008 Server. The other day, we experienced an issue where we almost ran out of space on one of our log drives. We had to carry out a dismount, move the logs via Ex Management Console to a another location, and then remount. > >This raises some questions for us...based on the article here: http://www.msexchange.org/articles/Exchange-log-disk-full.html > >Questions: > >1. Let's say we encounter the same problem again. We're not sure if a backup will finish before the space runs out. Is there any way to find out which logs have been commited and which not? The article mentions running ESEUtil /mk to interrogate the CHK file, however this can only be done when the DB is down, correct? No, you can run it while the datgabase is still mounted. >2. If we do dismount the store and run /mk, I'm still confused as to how we know which files have been commited and which not (the article doesn't really go into that!). Example, on my test machine, I have dismounted the store and the value is: > >Checkpoint: (0x53, 8, 16). > >I understand that I'm only interested in the 0x53, but how do I convert this into a log file? And is it anything before (and including) that log file I can move? The log file would be Exx00000053.log. Log files with lower numbers have already been committed to the database. If you're running out of space with only 83 log files you better rethink your storage! >3. When Exchange dismounts a store gracefully, aren't ALL log files for that store commited(assuming 1:1 relationship between store and SG)? In which case, we could move all the log files? Everyone *assumes* that all log files are committed, but that isn't *always* true. That's why you check the status of the database before you do anything. If you remove ALL the log files you'll restart the log sequence and you'd better make a full backup, pronto! >4. Would failing over to the passive CCR node help at all? Not really. The log files are there, too! >5. Is there anyway that the Toolbox (I'm thinking Database Recovery Toolset) can move the commited logs either before or after dismounting? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich for the great answering! Regarding this point: Checkpoint: (0x53, 8, 16) *btw, that's on a test system :-) How do you calculate the Exx00000053.log value, how did you get to that? And what does that .log file particularly mean - that Exchange has commited all log files before that, including it, or not including it? Secondly, say we were running out of space but the stores hadn't dismounted....is it a recommended procedure to run ESEUtil /mk to find out which logs have been commited already and then manually copy and paste them out whilst the store is still mounted? I guess that saves the downtime of dismounting the store and using the Exchange Management Console to move the log files to a different volume, but I'm not sure that moving log files whilst the store is still running is that safe? Then again, I did read somewhere that Exchange doesn't normally read from the log files anyway - the same uncomitted information is held in the database memory cache which Exchange reads from. It's only if the this memory cache crashes does Exch rely on the log files?

You just take the number and look at your files. It's in hex format. To see how many logs it represents, convert the number to decimal. 53 hex is 83 decimal - you can use the Windows calculator. In Exchange 5.5 the command used to give you the number in decimal and you had to convert it to hex. Newer versions give it to you in hex, which is how the files work. It represents the first uncommitted log file. So everything before that (counting in hex) has been committed but the log file referenced has not been committed.

On Thu, 30 Dec 2010 23:14:54 +0000, Chuck_P2101 wrote: > > >Thanks Rich for the great answering! > >Regarding this point: > >Checkpoint: (0x53, 8, 16) > >*btw, that's on a test system :-) > >How do you calculate the Exx00000053.log value, how did you get to that? Exx is the log file prefix. The "xx" will be value assigned by Exchange to the storage group. The 1st SG will use "00", the 2nd will use "01", etc. The rest of the file name is just the hexadecimal log file number from the "Checkpoint" data with zero-fill to the left to make it eight characters long. >And what does that .log file particularly mean - that Exchange has commited all log files before that, including it, or not including it? The value you find in the Exx.chk file is, until the database is dismounted, an inexact number because the file's not written to disk in "real time". It's the last log file that had transactions committed to the database. With the database dismounted and in a "clean shutdown" state, the value in the CHK file belongs to the log file named Exx.log file (i.e. the "current" log file). >Secondly, say we were running out of space but the stores hadn't dismounted....is it a recommended procedure to run ESEUtil /mk to find out which logs have been commited already and then manually copy and paste them out whilst the store is still mounted? No, it's not. The recommended practice is to make an "incremental" backup to get the log files somewhere safe and "purge" the ones that are no longer necessary from the log file directory. >I guess that saves the downtime of dismounting the store and using the Exchange Management Console to move the log files to a different volume, but I'm not sure that moving log files whilst the store is still running is that safe? Messing with the log files is the *last* thing you want to do. If you're short on space and it's only a "test system" then turn on circular logging. >Then again, I did read somewhere that Exchange doesn't normally read from the log files anyway - the same uncomitted information is held in the database memory cache which Exchange reads from. It's only if the this memory cache crashes does Exch rely on the log files? .. . . which is NOT the time to discover that you don't have the log files you need to bring the database to a consistent state -- even if you restred it from a backup! --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks again. > You just take the number and look at your files. It's in hex format. So, if value was (Checkpoint: (0x1B, 8, 16), then I would be looking for log E000000001B.log, is that correct? I just read the value given by the Checkpoint field, there is no need to carry out any conversion to find the log name? I just want to double check that please :-) > The value you find in the Exx.chk file is, until the database is dismounted, an inexact number because the file's not written to disk in "real time". Sorry, not sure what you mean by this? In my example, the Checkpoint value was E0000000053.log whilst the DB was mounted. Are you saying that this may not necessarily be the last log that was commited to the database? > The recommended practice is to make an "incremental" backup to get the log files somewhere safe and "purge" the ones that are no longer necessary from the log file directory Ah ok. So I guess this is much quicker than running a full backup and automatically purges the commited logs once the backup has run? Are there any disadvantages to this? I assume my normal, daily Full backups will still work and are unaffected? So, all in all, would you agree that - if I was in a Production situation where the log files location was running out of space, the best option by far is to run the Incremental backup whilst the DB is mounted. Second best is to dismount the database and, via Exchange Manager, move the log directory somewhere else with more space (which will also move the log files). The "option" of running /MK against the CHK file whilst the DB is mounted and then moving the 'commited' logs to somewhere else should not really ever be used? There is far too much danger in that. Thanks again for the contribution, very much appreciated! :-)

On Fri, 31 Dec 2010 11:47:57 +0000, Chuck_P2101 wrote: >> You just take the number and look at your files. It's in hex format. > >So, if value was (Checkpoint: (0x1B, 8, 16), then I would be looking for log E000000001B.log, is that correct? Yep. >I just read the value given by the Checkpoint field, there is no need to carry out any conversion to find the log name? I just want to double check that please :-) It really is as simple as that >> The value you find in the Exx.chk file is, until the database is dismounted, an inexact number because the file's not written to disk in "real time". > >Sorry, not sure what you mean by this? In my example, the Checkpoint value was E0000000053.log whilst the DB was mounted. Are you saying that this may not necessarily be the last log that was commited to the database? You really want to use the values in the CHK and EDB files together. Be conservative in what you remove -- keep the oldest log files found in either of them. >> The recommended practice is to make an "incremental" backup to get the log files somewhere safe and "purge" the ones that are no longer necessary from the log file directory > >Ah ok. So I guess this is much quicker than running a full backup and automatically purges the commited logs once the backup has run? Are there any disadvantages to this? I assume my normal, daily Full backups will still work and are unaffected? If you restore a backup you'll have to restore the log files, too. Since you don't have room to keep the log files now I don't think you'll be able to put the log files needed back on the disk. You could add additional disk space and restore to a RSG, then merge the mailboxes in the RSG with the mailboxes in a new (empty) database. >So, all in all, would you agree that - if I was in a Production situation where the log files location was running out of space, the best option by far is to run the Incremental backup whilst the DB is mounted. No, I wouldn't agree with that. The best option is to have sufficient space to hold the log files generated over a few days. That way you won't encounter a problem even if your "normal" backup (run every day) doesn't complete. Give yourself headroom. Planning is the way to avoid getting yourself into situations like this. >Second best is to dismount the database and, via Exchange Manager, move the log directory somewhere else with more space (which will also move the log files). This can take quite a while. You'll be creating lots of log files and moving them takes time. Make sure you don't short yourself on disk space for the log files in the first place. >The "option" of running /MK against the CHK file whilst the DB is mounted and then moving the 'commited' logs to somewhere else should not really ever be used? There is far too much danger in that. If you have thousands of log files (not an uncommon thing) then leave a few more of them in-place (even if that's a few hundred more). If you can, just leave the log files where they are and compress all but the latest of them. That's a safer thing to do that moving (or removing) log files. >Thanks again for the contribution, very much appreciated! :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP