We recently encountered an unusual problem with our Exchange Server cluster: We ran out of Exchange transaction log filenames. We were able to fix the problem but don't want it to happen again! Do you know what might have caused the situation and what we can do to prevent it from recurring? We're in a university environment that includes Microsoft Entourage 2004 for Mac clients.
Exchange sequentially numbers each transaction log file, beginning with E0000000.log and counting up (in hexadecimal format) from there. You can have a maximum of 1,048,575 unique log files, meaning that the last log filename you can have is E01FFFFF.log. This convention would seem to give you plenty of room: Each log file is exactly 5MB in size, so the scheme allows you about 5 trillion megabytes of log data. You'd think that would be plenty, especially because the log files are purged whenever you perform a full backup. However, Exchange doesn't reuse log filenames; if you needed to restore log files from a backup, you wouldn't want there to be any confusion about whether the E0012345.log file you just restored is the correct version or another generation that just happens to have the same name. However, in certain extreme circumstances, you might generate so many log files so fast that the limit causes a problem. For example, a bug in the release to manufacturing (RTM) version of Entourage 2004 can cause it to generate hundreds of log files per hour (depending on the number of Entourage users and what they're doing). It's my guess that this bug might be the culprit in your situation.
To keep from running into this problem again, you have two options. First, you can follow the Exchange Server Best Practices Analyzer (ExBPA) recommendation. When ExBPA detects that the current sequence number in a storage group (SG) is higher than a specified threshold value, the tool recommends that you perform a full backup, then immediately dismount the databases in the SG and perform an offline defragmentation of those databases. Second, the Microsoft article "A storage group has shut down and will not remount on Exchange 2000 Server or on Exchange Server 2003" (http://support.microsoft.com/?kbid=830408) documents an easier alternative: By moving the SG's log files and databases to a different path, you can effectively reset the sequence count. This action is best taken after an online backup, too. I prefer the second approach, but there's no practical difference between the two.
