Issues with Transaction Log Files When Moving an Exchange Mailbox Database
Topic Last Modified: 2005-10-12
Each Microsoft® Exchange database is associated with a transaction log file stream. All databases in a storage group share the same transaction log file stream. A database can be detached from one transaction log file stream and attached to a different stream. This change is what happens when you move a database from one storage group to another one.
While database files are in dirty shutdown state, they are still attached to the storage group log stream. Therefore, to move a database to a new storage group and log stream, you must first ensure that the database files are in clean shutdown state.
You cannot mix transaction logs from different streams in the same storage group. Therefore, when moving databases, you should leave behind the original transaction log files and transfer only clean shutdown database files.
When feasible, any transaction log replay should be done on the original server before files are moved. If it is necessary to move database files to different logical drive and folder paths than on the original server, you must run Exchange 2000 Server Service Pack 3 or later on the destination server.
The version of Exchange Server Database Utilities (Eseutil.exe) that comes with Exchange 2000 Server Service Pack 3 introduced the /D switch for soft recovery. This switch allows an administrator to override the database paths defined in each transaction log file.
Prior to this service pack, transaction log replay with Eseutil.exe required database files to be in the same logical path location as they were when the transaction logs were generated. This requirement was because the transaction logs store the location of the databases they belong to and expect the databases to be in the stored path.
For example, if databases are in C:\Databases at the time a series of transaction logs is generated, and you later move the databases to D:\Databases, then subsequent transaction log replay will result in a “File not found” error. (The transaction log replay process will still read all logs and finish, but no data will actually be applied to any database for which a “File not found” error is reported.)
The Exchange 2000 Service Pack 3 version of Eseutil.exe provides a new transaction log replay switch that allows an administrator to override the database path written in the transaction log files. Thus, transaction log replay can succeed regardless of the current location of the database files.
To use this new Eseutil.exe functionality, follow these steps:
Copy the databases to be recovered and all transaction log files to be replayed into a single folder together.
Open a command window, and then set the default directory to the folder that contains all the database and transaction log files.
Run the following command:
C:\Program Files\Exchsrvr\Bin\Eseutil.exe /R Enn /DC:\Program Files\Exchsrvr\Bin\Eseutil.exe /R E00 /D
Note: You should substitute the log prefix for the storage group for Enn in the above command. The log prefix is the first three characters of the transaction log filenames for the storage group. For example:
Running this Eseutil command from the folder that contains both the databases and transaction log files allows you to simplify the command line by omitting full path specifications and additional command line parameters. Running Eseutil in this way is strongly recommended. Refer to Eseutil documentation for more information about advanced command line parameters.
Note: It may be necessary to add the /I switch to the command line if you are not recovering all databases in a storage group simultaneously. The /I switch instructs Eseutil.exe to ignore missing database files during recovery. For example: C:\Program Files\Exchsrvr\Bin\Eseutil.exe” /R E00 /I /D
For more information about moving Exchange mailbox databases, see Moving an Exchange Mailbox Database to Another Server or Storage Group.
For more information about issues with the System Attendant mailbox when moving Exchange mailbox databases, see Issues with the System Attendant Mailbox When Moving an Exchange Mailbox Database.