Moving Exchange logs urgently
Occasionally, during my time as an Exchange admin, I've come across problems with transaction logs and lack of space. Now that disk space is cheaper, we generally size for the failure of 3 night of backups, but we do still hit backup problems and also excessive log generation. I was curious to know what other experts in the field's opinion was on the following situation. Let's say, for whatever reason, we've had some problems with our backups and disk space is a bit low. We then have an issue where log files are being generated quite quickly. We're running Exchange 2007 SP2. I don't want to dismount the store and cause problems for users, so the best thing to do is move older log files out. What do people recommend - 1. Copy and paste older log files (days old) to another drive. This means that once the copy has completed (could take a while), I'd have to go back to the original folder and delete the copied logs. 2. Cut and paste older log files (days old) to another drive. Quicker than above, but means that if there is a problem with the cut and paste process, some logs may 'disappear'. 3. I know with the Exchange Management Console's Database Troubleshooter, there is a tool that will tell you which logs have been commited and the option for Exchange to move them. Has anyone does this on a mounted DB? 4 In terms of finding out which client is causing excessive logs, I have heard using ExMon is good. Should that be installed on my PC, on the troublesome Exchange server etc? Thanks in advance.
January 30th, 2011 7:21am

On Sun, 30 Jan 2011 12:16:09 +0000, Pancamo wrote: > > >Occasionally, during my time as an Exchange admin, I've come across problems with transaction logs and lack of space. Now that disk space is cheaper, we generally size for the failure of 3 night of backups, but we do still hit backup problems and also excessive log generation. I was curious to know what other experts in the field's opinion was on the following situation. > >Let's say, for whatever reason, we've had some problems with our backups and disk space is a bit low. We then have an issue where log files are being generated quite quickly. > >We're running Exchange 2007 SP2. I don't want to dismount the store and cause problems for users, so the best thing to do is move older log files out. > >What do people recommend - > >1. Copy and paste older log files (days old) to another drive. This means that once the copy has completed (could take a while), I'd have to go back to the original folder and delete the copied logs. > >2. Cut and paste older log files (days old) to another drive. Quicker than above, but means that if there is a problem with the cut and paste process, some logs may 'disappear'. > >3. I know with the Exchange Management Console's Database Troubleshooter, there is a tool that will tell you which logs have been commited and the option for Exchange to move them. Has anyone does this on a mounted DB? > >4 In terms of finding out which client is causing excessive logs, I have heard using ExMon is good. Should that be installed on my PC, on the troublesome Exchange server etc? On the server. I'd rather compress the log files I know aren't needed to return a database to a consistent state before I resort to moving anything. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
January 30th, 2011 12:49pm

On Exchange 2007, I think most would recommend that backups be performed regularly. If they are failing, that is the problem that needs to be fixed. I've seen more than one Exchange admin be walked out the door because the ball was dropped on backups. Now, while you are working on making sure that your backups always work, there are some workarounds. #1 is a good idea, #2, eh, depends on how comfortable you are with it. I've never used the Database Troubleshooter. exmon is a good tool to tell you who is really using your resources. More detailed log generation troubleshooting here: http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx but remember, normal use generates a log of logs, so you may not be able to pin it on a specific user. Don't forget the real issue, making sure the backups are reliable. JoeJoseph M. Durnal MCITP: Enterprise Messaging Administrator
January 31st, 2011 2:23am

Rich made an excellent suggestion regarding compressing the logs to conserve space until you can figure out your situation. This of course doesn't solve the problem but it does give you some temporary breathing room while allowing you to keep all the logs. The other possibility is to A. take the store down to ensure that all logs are committed, B. rename the log path i.e. ExchsrvrLogs --> OldExchsrvrLogs C. create a new log path folder to replace the renamed path and then D. bring the store back online. Next you can zip the old log path to save space and to retain the logs for recovery purposes. As stated earlier this is of course not a recommended way to resolve the issue but could give you some breathing room until you can figure out the problem and resolve it. You could also temporarily enable circular logging, http://technet.microsoft.com/en-us/library/bb331968(EXCHG.80).aspx which would flush all the logs, HOWEVER it does require a information store service restart but that takes literally a minute. Once the logs are flushed disable circular logging and take an IMMEDIATE backup. This post might help you track down the cause of which client is causing a problem. http://blogs.msdn.com/b/scottos/archive/2007/07/12/rough-and-tough-guide-to-identifying-patterns-in-ese-transaction-log-files.aspx?PageIndex=2#comments Troy Werelius www.Lucid8.com
Free Windows Admin Tool Kit Click here and download it now
January 31st, 2011 12:25pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics