For Exchange Server 5.5
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 (http://support.microsoft.com/kb/322756/) How to back up and restore the registry in Windows
| 1. |
In the Exchange Server Administrator program, view the working path for the database.
Path locations are found on the Database Paths properties page of the Server object. The checkpoint file (Edb.chk) is located in this path. If the Administrator program is unavailable, you can view the working path in the system registry. Run Registry Editor and expand the following registry subkeys.
For the information store:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory For the directory:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\DSA Working Directory
|
| 2. |
At a command prompt, move to the working path folder. View the header of the Edb.chk file by using the Eseutil command:
eseutil /mk edb.chk Note that the screen output is similar to the following:
Microsoft(R) Windows NT(TM) Server Database Utilities
Version 5.5
Copyright (C) Microsoft Corporation 1991-1998. All Rights Reserved.
Initiating FILE DUMP mode...
Checkpoint file: edb.chk
LastFullBackupCheckpoint (0,0,0)
Checkpoint (157,2860,500) comment: Checkpoint is in log 157 decimal
FullBackup (90,8,10)
FullBackup time:1/15/1999 18:18:36
IncBackup (0,0,0)
IncBackup time:0/0/1900 0:0:0
. . .
The three numbers on the Checkpoint line represent the log file generation number, a sector offset into the log file, and a byte offset into the sector. Write down the generation number.
|
| 3. |
Convert the generation number into hexadecimal. In this example, decimal 157 translates to hexadecimal number 9D. Exchange Server log files are numbered with five hexadecimal digits. For example, a log file can be named as Edb12345.log. Leading zeros are used to pad the log number out to five digits. Therefore, the checkpoint log file from the previous example is Edb0009d.log.
Note You can use the Scientific mode of the Windows Calculator to convert from decimal to hexadecimal. Start the Calculator. Then, click Scientific on the View menu. Enter the decimal number, and then click Hex. |
| 4. |
The checkpoint log and all logs generated after the checkpoint log are required to start a database when the database is in an Inconsistent state. You may not find a log file that corresponds to the checkpoint value that you calculated. This can occur if the checkpoint is in the most recent log file that is always named Edb.log. Until this log is full and until a new log is generated, the file name of the current log does not include the log sequence number.
You can verify the actual internal sequence number of the Edb.log file by viewing the log file header by using the following Eseutil command:
eseutil /ML Edb.log The lGeneration field of the log file header reflects the actual sequence number of the log file. You must convert the lGeneration value to hexadecimal.
|
| 5. |
You can safely remove all numbered logs less than the checkpoint log. However, do not remove the checkpoint log itself. In this example, you can remove Edb0009c.log, Edb0009b.log, and so on, but not Edb0009d.log or the current log. Remember to move, not delete, the log files. You do not have to stop the database service to remove log files that are older than the checkpoint. |
If you must restore a backup, you must also restore all log files that are created after that backup if you want to completely roll the database forward. If there is a break in the sequence of logs, you cannot roll forward past the break.