ESE - 514
- Source » ESE
- Event ID » 514
- Type » Warning
- Category » Logging/Recovery
- User » N/A
- Computer » LOCALCOMPUTERNAME
- Log » Application
- Opcode »
- Keywords »
- InstanceID » 0
Description »
Information Store (4788) Storage Group 1: Log sequence numbers for this instance have almost been completely consumed. The current log generation is 918000 (0x000E01F0) which is approaching the maximum log generation of 1048559 (0x000FFFEF), there are 130559 (0x0001FDFF) log generations left to be used. To begin renumbering from generation 1, the instance must be shutdown cleanly and all log files must be deleted. Backups will be invalidated.Data formatted as » None
This event will be logged on servers running Exchange 2000/2003 when the Exchange log sequence numbers begin to run out. This is logged in the hope that you will reset the sequence numbers, and avoid an unplanned outage on your Exchange server such as that described in MS KB830408. As explained in The Exchange Team Blog, the first warning will appear when a storage group reaches log sequence number 0xE0000 (917504) - which means you've used just over 87.5% of all available log sequence numbers. For your fourth storage group, the log file would be called E03E0000.log. The event will be logged again for every 1,000 log sequence numbers used on that storage group. When the storage group reaches log sequence number 0xFF000 (1044480), meaning you've used 99.61% of all available log sequence numbers - the entry will be logged once for every 10 log numbers used. Once all numbers are exhausted, the store will dismount, and event ID 1159 from MSExchangeIS will be logged. And you will be sorry.
If you look after Exchange 2000/2003 servers, this eventlog entry is definitely worth trapping for.
Here's a brief change plan I wrote to reset some logs on a clustered Exchange 2003 server recently:
Part 1 - Dismounting the store and databases.
Assuming SG2 (steps will need to be repeated for each Storage Group):
- Logon to EX017 as -admin-exch, and open Exchange System Manager.
- Expand Administrative Groups, expand "London", expand Servers, expand "EXCH-CLUS08", and then expand "Storage Group 2".
- Right-click Priv1, and click Dismount Store. Repeat this step for Priv2, Priv3 and Priv4.
- Open a command prompt
- Change directory to the Exchsrvr bin folder:
cd "C:\Program Files\Exchsrvr\bin" - Run the following commands to check that each database is cleanly shutdown:
eseutil /mh T:\SG2\Priv1\Priv1.edb
eseutil /mh T:\SG2\Priv2\Priv2.edb
eseutil /mh T:\SG2\Priv3\Priv3.edb
eseutil /mh T:\SG2\Priv4\Priv4.edb
If you see "State: Clean Shutdown" for all databases, it is safe to proceed. Skip to part 3 (resetting the logfiles). If you see "State: Dirty Shutdown" for any database, it must be recovered as describe in part 2...
Part 2 - Recovering databases in 'Dirty shutdown' state:
If you have databases which are not in a 'clean' shutdown state, perform the following steps:
- In your command prompt window (still in the Exchsrvr\bin directory), run the following:
Eseutil /r E01 /lDirectory:W:\Logs\SG2 /sDirectory:W:\Logs\SG2 - Once this has completed, run the "eseutil /mh T:\SG2\Priv1\Priv1.edb" commands again for the databases which were in a dirty state, and verify that they are now showing 'clean shutdown'.
- If the databases are still not in a clean shutdown state, you must abort this change and bring the storage group back online. If the databases are in a clean shutdown state, you can now safely proceed to part 3:
Part 3 - Resetting the Sequence
- Navigate to W:\Logs\SG2
- Move all files with the .LOG extension to another drive with space - most likely to R:\TEMP. Also move the E01.CHK file here. Wait for the files to finish moving before proceeding to the next step.
- In Exchange System Manager, right-click Priv1, and click Mount Store. Repeat this step for Priv2, Priv3 and Priv4.
- Once all mail stores are back online, start a full backup of SG2.