Microsoft Exchange Server Database Utility Guid
Exchange Server Database Utility Guide............................................................................. 7
Exchange Server Database Utility Guide
When a database is corrupt or damaged, data can be restored from backup or repaired using Eseutil. Eseutil is a command line utility that works with Extensible Storage Engine (ESE), database (.edb) files, streaming (.stm) files, and log (.log) files associated with an Information Store, in a given Storage Group. Eseutil is located in the C:\Program Files\Exchsrvr\Bin folder in Exchange Server 2000 and in Exchange Server 2003. The tool can be run on one database at a time from the command line and can be used to perform a range of database tasks from repair, offline defragmentation, and integrity checks in Exchange Server 5.5, Exchange Server 2000, and Exchange Server 2003. The most common Eseutil switches are listed in the table below.
Note:
Download Microsoft Exchange Server Database Utility Guide to print or read offline.
Eseutil Repair, mode can be used to repair a corrupt or damaged database while recovery and restore modes can be used to replay transaction log files into a database. The file header dump modes can be used to correlate database and transaction log files and to determine other information about them. The checksum mode can be used to verify the file integrity of a database. The copy file mode is useful for very rapid copying of large files. The defragmentation mode can be used to compact a database offline, reducing the size of the database files by removing empty space.
Topics in this guide give you an understanding of the Eseutil repair tool, tell you about scenarios where you can use the tool, discuss the different modes giving instructions on how to run Eseutil in those modes, and provide help with troubleshooting common Eseutil errors. For more information about common Eseutil errors, see Reference for Common Eseutil Errors.
| Eseutil Mode | Switch | Description |
| Defragmentation | /D | Eseutil defragments the database files. This mode reduces the gross size on disk of the database (.edb) and streaming files (.stm) by discarding most empty pages and ad hoc indexes. For more information, see these topics: |
| Repair | /P | Eseutil repairs corrupt database pages in an offline database but discards any that can't be fixed. In repair mode, the Eseutil utility fixes individual tables but does not adjust the relationships between tables. ISInteg should be used to check logical relationships between tables. For more information, see these topics: |
| Restore | /C | Eseutil displays the Restore.env file and controls hard recovery after restoration from online backup. For more information, see these topics: |
| Recovery | /R | Eseutil replays transaction log files or rolls them forward to restore a database to internal consistency or to bring an older copy of a database up to date. For more information, see these topics: |
| Integrity | /G | Eseutil verifies the page level and Extensible Storage Engine (ESE) level logical integrity of the database but does not verify database integrity at the Information Store level. For more information, see these topics: |
| File Dump | /M | Eseutil displays headers of database files, transaction log files, and checkpoint files. The mode also displays database space allocation and metadata. For more information, see these topics: |
| Checksum | /K | Eseutil verifies checksums on all pages in the database and streaming files. For more information, see these topics: |
| Copy File | /Y | Eseutil performs a fast copy of very large files. For more information, see these topics: |
ISInteg
The ISInteg utility is most often used after an Eseutil repair operation. It can also be used when an event or error warrants it. Several Microsoft Knowledge Base articles recommend the use of ISInteg for resolving specific issues.
ISInteg corrects database problems at the application level of the database. Eseutil corrects database problems at the ESE level. ISInteg understands the database as a collection of mailboxes and items in them, and can correlate and repair information and relationships between mailboxes, folders, items and attachments.
ISInteg was originally created as a utility for internal use by testers in the Exchange development group, and was released publicly because of its general usefulness. It can perform multiple independent and interrelated tests of the database, and can fix discrepancies found. ISInteg cannot comprehensively correct all possible problems in the database, but it is often very successful. Over time, ISInteg has been incrementally improved to make it more robust and useful.
For More Information
For more information about database recovery strategies, see Database Recovery Strategies.
For more information about common Eseutil errors, see Reference for Common Eseutil Errors.
For more information about the ISInteg utility, see the Microsoft Knowledge Base article 182081 "Description of the Isinteg utility" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=182081).
For more information about repairing Exchange databases and disaster recovery, see the Exchange Server 2003 Disaster Recovery Operations Guide (http://go.microsoft.com/fwlink/?LinkId=47570).
For more information about understanding Extensible Storage Engine (ESE) file types, see Extensible Storage Engine Files (http://go.microsoft.com/fwlink/?LinkId=68167).
Eseutil's /D switch can be used to defragment and compact a database offline. The defragmentation option makes used storage contiguous, eliminates unused storage, and compacts the database thereby reducing the database's size. For instructions about how to use the Eseutil /D syntax, see How to Run Eseutil /D (Defragmentation).
Eseutil's /D switch can be used to defragment and compact a database. During typical operations, database files never shrink below their current size. As space in the database is freed by deletion of items, existing pages are reused where possible. Typically, a Microsoft® Exchange Server database will grow for several months after it is put in service, but eventually the database size stabilizes.
Under typical conditions, performing an offline defragmentation will not permanently recover significant disk space. The file will usually grow again to its previous un-defragmented size. Special circumstances, such as moving many mailboxes out of the database, may make it worthwhile to defragment the database offline. By default, during typical operation, the database is logically defragmented nightly. This does not reduce the size of the file on disk, but does make the database perform efficiently.
Note:
You can use the Eseutil utility to defragment the information store and directory in Microsoft Exchange Server 5.5 and to defragment the information store in Microsoft Exchange 2000 and newer versions.
How Does Eseutil Defrag Work?
When Eseutil defragments a database by eliminating unused storage and compacting the database, Eseutil actually creates a new database that contains all the information from the original database. When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is copied over the original. If the utility encounters a serious logical problem in the database, defragmentation stops. The database must then first be repaired with Eseutil /P before it can be defragmented.
When an offline defragmentation is performed, Exchange makes temporary copies of the database file (.edb file) and the streaming database file (.stm file). Tables from the .edb file are preserved and copied into the temporary database, but empty pages and indexes are discarded. Because this causes physical page numbers in the database to be changed, pages are not copied unaltered; the page links between them are all updated, and all pages left in the database undergo integrity checks. All pages in the .stm file that has information on them are preserved in the temporary .stm file, and references to the pages are updated in the .edb file.
How Long Does it Take to Defragment a Database?
The time length to complete defragmentation depends on how much of the database is empty, and not on the size of the database file. For example, defragmenting a 100 GB database that contains 10 GB of data takes about the same time as defragmenting an 11 GB database that contains 10 GB of data.
By default, after defragmentation is completed, the temporary database automatically becomes the new production database, and the original production database is deleted. The time that defragmentation takes can be significantly reduced if you have as much free space on the same logical drives as the size of the original database files. In this case, the temporary database can be put on the same logical drive, and the final copy will complete almost instantly.
We do not recommend that you use a network drive to hold the temporary database. When you use a network drive for the temporary database, defragmentation will take longer, and any transient or permanent network error will end the process. Because defragmentation cannot be resumed, you would have to start over from the beginning.
Note:
You only need as much extra logical drive disk space as the final size of the files after defragmentation. Although it is impossible to exactly predict how much disk space will be reclaimed, you should leave a recommended 110% of free disk drive space to be safe. For more information about how to determine the amount of disk space for defragmentation, see the Microsoft Knowledge Base article 195914, "Determining database free space with Exchange 5.5 Service Pack 1 and later versions of Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).
When to Run Eseutil /D?
There are several situations where it is appropriate to run Eseutil /D to defragment an Exchange database. The following includes a list of those situations:
· There is a significant amount of white space in the database that can be reclaimed and which will not be reused. An example can be when the number of mailboxes in the database has been significantly reduced.
· An event is repeatedly logged in the Application log advising you to defragment the database offline. This may occur rarely when typical online defragmentation is no longer able to efficiently defragment the database.
· When the 16 GB database size limit is reached on the Standard version of Exchange and white space must be reclaimed in order to mount the database. If you are running Exchange Server 2003, then Service Pack 2 (SP2) should be installed to raise the limit to 75 GB. For more information about increasing the database size limit, see Microsoft Knowledge Base article 828070, "Exchange Server 2003 mailbox store does not mount when the mailbox store database reaches the 16 GB limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).
Note:
After defragmenting the database using Eseutil, we recommend that you perform a full backup of the database. A full backup is needed because the database defragmentation creates new database files which have new database signatures. Log file replay after the restore depends on database signatures to match the expected values recorded in transaction log files. Any database backups that are taken before the defragmentation will contain database files that have signatures different from the new defragmented database. If an older database is restored, the new transaction logs which are bound to the new defragmented database files will not replay.
When not to Run Eseutil /D?
There are situations where it is not appropriate to run Eseutil /D to defragment an Exchange database. The following includes a list of those situations:
· Eseutil defrag should not be run as any kind of standard maintenance. Exchange runs an automatic online defragmentation nightly that handles the day-to-day maintenance of Exchange. There is no reason to periodically run an offline defragmentation unless special circumstances apply.
· Eseutil defrag cannot not be run when the database is not in a consistent state.
Note:
As a rule, unless you expect more than 20 percent of available space to be recovered, defragmentation will likely not cause permanent shrinkage of the database files.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Database Recovery Strategies
· Reference for Common Eseutil Errors
This section explains how the Eseutil command can be used to defragment, and or compact Exchange database files offline for all versions of Exchange. For more information about understanding Eseutil /D, see Eseutil /D Defragmentation Mode.
Before You Begin
Before you defragment a database using Eseutil, note the following:
1. Make sure you have free disk space equal to 110 percent of the end size of the database that you want to process (the end size being the current file size minus the size of the white space in the file).
2. Dismount the database before defragmenting as Eseutil performs an offline defragmentation. During the offline defragmentation the dismounted database will be inaccessible to clients.
Procedure
How to defragment an Exchange 2000 or Exchange 2003 database
| 1. In Exchange System Manager, right-click the database that you want to defragment, and then click Dismount Store. 2. At the command prompt, change to the Exchsrvr\Bin folder, and then type the Eseutil /d command, a database switch, and any options that you want to use. For example, the following command (all on one command line) runs the standard defragmentation utility on a mailbox database: C:\program files\exchsrvr\bin> Eseutil /d c:\progra~1\exchsrvr\mdbdata\priv1.edb Use the following database switch to run Eseutil defragmentation on a specific database: Eseutil /d <database_name> [options] |
How to defragment the Exchange Server 5.5 database
| 1. Stop the service that controls the database you wish to defragment by using the Services applet in Control Panel. · For the Exchange Directory database, stop the Microsoft Exchange Directory service. · For the Exchange Mailbox or Public Folder databases, stop the Microsoft Exchange Information Store service. 2. At the command prompt, change to the Winnt\System32 folder, and then type the Eseutil /d command, a database switch, and any options that you want to use. For example, the following command runs the standard defragmentation utility on the directory and saves the copy in the user-defined file: C:\winnt\system32> Eseutil /d /ds /tc:\dbback\tempdfrg.edb /p Use one of the following database switches to run Eseutil on a specific database. Option Description ---------------------------------------- /ds Directory /ispriv Private information store /ispub Public information store Use one or more of the following options to specify the operations that you want to perform on the database. |
Command line reference
This is the command line reference that can be seen by typing Eseutil ./? at the command prompt in the Exchsrvr\Bin folder, and the selecting D for defragmentation
DEFRAGMENTATION/COMPACTION:
DESCRIPTION: Performs off-line compaction of a database.
SYNTAX: ESEUTIL /d <database name> [options]
PARAMETERS: <database name> - filename of database to compact
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name (default: TEMPDFRG*.EDB)
/f<file> - set temp. streaming file name
(default: TEMPDFRG*.STM)
/i - do not defragment streaming file
/p - preserve temporary database (ie. don't instate)
/b<db> - make backup copy under the specified name
/8 - set 8k database page size (default: auto-detect)
/o - suppress logo
NOTES: 1) If instating is disabled (ie. /p), the original database
is preserved uncompacted, and the temporary database will
contain the defragmented version of the database.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Database Recovery Strategies
· Reference for Common Eseutil Errors
The Eseutil repair mode corrects database problems at the page and Extensible Storage Engine (ESE) table levels but not at the application level. After repairing a database using Eseutil, ISInteg should be run to repair the database at an application level. To understand what database page level, ESE table levels, and application levels mean, see Database Recovery Strategies. For more information about syntax and instructions for using Eseutil /P, see How to Run Eseutil /P (Repair) in Different Scenarios.
During repair, it may be necessary to discard rows from tables or even entire tables. After completing the ESE-level repairs, it is necessary to perform an application-level repair to correct problems that may now exist at the application level because of missing data. The Information Store Integrity (ISInteg) utility can be used to perform this Exchange application-level analysis and repair. The following example explains how Eseutil repair works.
For example, a table in the database stores messages for all mailboxes. A separate table is used for each user's Inbox folder. Suppose that a message is lost when using Eseutil to repair the message table. Eseutil will not correlate the message with the reference to it in each Inbox folder, because Eseutil does not understand the cross-table schema of the application. ISInteg is needed to compare the repaired message table with each Inbox folder, and to remove a lost message from the Inbox.
In short, Eseutil looks at each Exchange database page and table and ensures consistency and integrity within each table. ISInteg, recommended to be run after Eseutil, repairs a database at the application level and ensures the integrity of the relationships between tables.
Repairing databases involves the following three stages, in this order:
1. Eseutil is run in /P mode to perform a database page-level and table-level repair
2. Eseutil is run in /D mode to fully rebuild indexes and defragment the database
3. ISInteg is then run to repair the database at the application level
Note:
A successful repair does not necessarily mean that a database will always be useable. The loss of system metadata may leave a database unmountable or empty. When a database is not repairable, you can restore data from backup or create a new database.
Placing a Repaired Database Back Into Production
It is a judgment call whether to leave a repaired database permanently in production. The policy of many administrators is to use repaired databases only for data salvage. Administrators move mailboxes as soon as possible to another database, or merge the data from a repaired database into a known good database.
Both Eseutil and ISInteg generate detailed repair log files that list the errors found and corrected. For more information about causes and consequences of specific errors, you can search the Microsoft Knowledge Base and see the topic on Reference for Common Eseutil Errors. Information from these areas can help you decide whether you wish to accept the risks of leaving a repaired database in production.
Eseutil /P Best Practice
Use Eseutil /P when you cannot restore a database from backup or when you cannot fully roll transaction logs forward.
Note:
If you cannot roll forward transaction log files, a hybrid strategy is best to follow. You can restore a working version of the database from backup, repair the damaged database in the recovery storage group, and merge the two databases.
Microsoft recommends that you follow these best practices when repairing a database:
· Do not allow a repaired database to remain in production for an extended period of time.
· Do not use the Eseutil repair option when backup is available.
· Do not use Eseutil repair mode to expunge a -1018 error. For more information about error -1018, see Microsoft Knowledge Base article 812531, "Support WebCast: Microsoft Exchange: Understanding and Resolving Error -1018" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=812531).
Previous Exchange Versions
The table below explains how the Eseutil repair mode works in different versions of Exchange:
| Exchange 200x | By default, detailed logging of the repair process is stored in a plain text file called database.integ.raw. This log will tell you exactly which tables were repaired and what problems required their repair. |
| Exchange 5.5 | It was necessary to specify verbose logging with the /V switch to see similar detail. |
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
The Eseutil syntax and behaviors described in this section apply to Exchange Server 2003 Service Pack 2 (SP2), and give instructions for running the Eseutil repair on your database. The Eseutil repair mode corrects corrupted or damaged databases at the page and table levels, but not at the application level. A repair may complete successfully, leaving all database tables consistent, but with the database so severely damaged that it cannot be mounted. For more information about the Eseutil repair mode, see Eseutil /P Repair Mode.
Before you begin
Consider the following points before running the Eseutil repair mode on your database:
· There must be sufficient disk space on the local logical drive for the temporary repair database. Keeping 20 percent of the size of the database files being repaired is suggested, although the size of the temporary file will vary widely depending on the nature of the repairs made. If sufficient space is unavailable, you may redirect temporary files to a different drive, as described below.
· The streaming database (.stm file) must be in the same folder as the Messaging Application Programming Interface (MAPI) database (.edb file), or you must set a command line switch to identify the path for the streaming database, as described below.
Procedure
To run Eseutil /P
| · The basic command line syntax for repairing a database with Eseutil is: ESEUTIL /P database_filename.edb
With Exchange Server 5.5, you need to run /V to see the verbose logging that is default with Exchange 2000 Server and later versions. |
You may encounter these scenarios when running Eseutil repair against your database:
· Database and streaming files don't match
· Streaming file is missing
Database and Streaming Files Don't Match
Some hard crashes may leave the database and streaming databases out of synch with each other, or you may have obtained a streaming database that is out of date with the database file. By default, repair will check for this problem at the beginning, and exit to give you a chance to obtain the correct file if it is available.
You can force repair to continue past this problem, but if the streaming file is one that does not actually belong with the database, this will not salvage data from it. Instead, all data will be deleted from the streaming file. Force a mismatch to be ignored only when you are very confident that the streaming and database files belong together, and that they are close to being in synch with each other.
The streaming database is composed entirely of raw user data. All logical structure and ownership information about the data is in the MAPI database (.edb file). All data in the .stm file that does not match the pointers in the .edb file will be lost during a repair.
Follow these steps for running Eseutil /P to ignore a streaming file mismatch:
To ignore streaming file mismatch
| · To ignore a streaming file mismatch, add the /I switch to the Eseutil command line. For example: ESEUTIL /P priv1.edb /I |
Streaming File is Missing
If the streaming database has been destroyed, or is missing, you can still successfully complete a repair, but with the loss of all data in that file. If the majority of your users are MAPI clients (Microsoft® Office Outlook® users), the data loss involved may be negligible. If most users connect via Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4), the data loss is likely to be catastrophic.
Follow this step to run Eseutil /P when a database streaming file is missing or when repair is unable to finish with the current streaming file:
To create a new streaming file
| · To create a new streaming file, use the /CREATESTM switch. For example: ESEUTIL /P PRIV1.EDB /CREATESTM |
Post-Repair Considerations
Remember the following points after you have run Eseutil /P to repair your database:
· Perform a full backup of the database as soon as possible after a repair. Repair invalidates previous backups. This does not mean that previous backups cannot be restored or are completely worthless. It means that repair makes it impossible to completely roll the database forward from a previous backup. If you restore a previous backup, transaction log file replay will end at the point at which the repair was done. Any changes to the database subsequent to the repair cannot be put back into a restored database. Therefore it is critical that you perform a full backup of the database as soon as possible after a repair.
· Remember that you must run defrag (Esetuil /D) and ISInteg -fix to finish repair. Only if you intend to use the repaired database for salvage and then discard it can you skip these extra steps. Skipping them means that you may salvage less data than if you completed them, but it can also mean saving several hours of recovery time.
Important:
You must perform a full backup of the database, run defrag, and run ISInteg before placing a repaired database back in production. Microsoft IT's best practice is to move a mailbox as soon as it is feasible rather than to leave a repaired database indefinitely in production. For more information, see Eseutil /P Repair Mode.
Command line reference
This is the command line reference that can be seen by typing Eseutil ./? at the command prompt in the Exchsrvr\Bin folder, and the selecting P for repair.
REPAIR:
DESCRIPTION: Repairs a corrupted or damaged database.
SYNTAX: ESEUTIL /p <database name> [options]
PARAMETERS: <database name> - filename of database to repair
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name
(default: TEMPREPAIR*.EDB)
/f<name> - set prefix to use for name of report files
(default: <database>.integ.raw)
/i - bypass the database and streaming file mismatch error
/g - run integrity check before repairing
/createstm - create empty streaming file if the file is missing
/8 - set 8k database page size (default: auto-detected)
/o - suppress logo
NOTES: 1) Repair does not run database recovery. If a database
is in a "Dirty Shutdown" state it is strongly
recommended that before proceeding with repair,
recovery is first run to properly complete database
operations for the previous shutdown.
2) The /i option ignores the signature mismatch error in
the check phase if the database and streaming file do
not match each other. The database and streaming file
will receive new signatures in the repair phase. Without
using this option, repair will terminate immediately
once the database and streaming file mismatch error occur
3) The /g option pauses the utility for user input before
repair is performed if corruption is detected. This optio
overrides /createstm and /o options.
4) The /createstm option is irreversible. Once you
start the repair process a new streaming file will
be created. Any streaming file that existed before
the repair will no longer work with this database.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
The Eseutil restore mode allows you to run hard recovery on a database restored from online backup, and to view the Restore.env file. The Restore.env file is created during restoration of an online backup, and it controls the hard recovery process. For more information about running Eseutil /C, see How to Run Eseutil /C (Restore) in Different Scenarios.
The term "hard recovery" refers to the process that controls transaction log file replay into a database that has been restored using the legacy online streaming backup application programming interface (API). This process is different from transaction log replay that occurs after a database crash or after restoring a database using the Volume Shadow Copy Service (VSS) backup API.
Backup applications that implement the Exchange legacy streaming online backup API provide a setting in the user interface to start hard recovery after the last backup set has been restored. In Microsoft® Windows NT® NTBackup, it is called "Last Backup Set."
If you fail to trigger hard recovery from the backup application, you must run hard recovery manually from the command line with Eseutil before a restored database can be mounted.
Note:
If you run the Eseutil restore commands from where the Restore.env file exists, the command syntax is very simple. Otherwise, you must add path information to the switches. Therefore, it is strongly recommended that you run these commands from the Restore.env location.
For More Information
For more information about database recovery, see Recovering an Exchange Database (http://go.microsoft.com/fwlink/?LinkId=67227).
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
This section explains the command line syntax and transaction log file replay for running a hard recovery using Eseutil restore on your database. The Eseutil restore mode allows you to run hard recovery on a database restored from online backup, and to view the Restore.env file. The Restore.env file is created when restoring a database from online backup, and it controls the hard recovery process. For more information about Eseutil /C, see Eseutil /C Restore Mode.
Before You Begin
Important:
The Eseutil /CC command may not work with Exchange 2000 Server running on a cluster server, and you may receive the following error message: Error returned from a callback function call (0x8004010F). Operation terminated with error -107 (JET_errInternalError, Fatal internal error).
For more information about this error, see Microsoft Knowledge Base article 266689, "The "eseutil /cc" command does not work on cluster server."
Procedure
To run Eseutil /C
| · To view the Restore.env file use this basic command line syntax: ESEUTIL /CM "d:\temp\First Storage Group"
If you run the command from the directory where Restore.env exists, it is not necessary to specify any path information. If you specify path information, do not append Restore.env to the end of the path. · To run hard recovery, execute the following command line syntax: ESEUTIL /CC "d:\temp\First Storage Group"
If you run the command from the directory where Restore.env exists, it is not necessary to specify any path information. If you specify path information, do not append Restore.env to the end of the path. For more information about running Eseutil /CC, see "How to Run Eseutil /cc" (http://go.microsoft.com/fwlink/?LinkId=67228). · To force a non-victimized database to be recovered, you can run the following command as if the database has been victimized, as in the example below: ESEUTIL /CC /T
Do not use any parameters with the /T switch. Use of the /T switch will cause all transaction logs in the Restore.env location to be replayed, whether they are listed in the Restore.env file or not. No logs in the running folder will be replayed. |
Controlling Transaction Log File Replay.
Transaction log file replay behavior using Eseutil /CC depends on whether the database has been victimized or not.
Note:
If you are unsure about the victimization status of a database, copy log files into both the temporary and running folders. This will ensure that one log copy or the other will be considered for replay.
If a database has NOT been victimized, transaction logs will be replayed as follows:
· The sequence of log files listed in the Restore.env file will be replayed first.
· If additional log files exist in the Restore.env location, they will not be replayed under any circumstances.
· If additional matching log files exist in the running storage group log folder and they are in contiguous sequence with the files listed in Restore.env, they will be replayed.
· If additional log files exist in the running storage group log folder and they do not match or are not in contiguous sequence and circular logging has been disabled, then an error will occur and hard recovery will fail. To resolve such errors, matching and contiguous log files must be located, or you can use Eseutil /CC /T switches to ignore log files in the running folder and to replay only log files listed in the Restore.env file.
· If circular logging is currently enabled or was enabled at the time the backup was made, then only log files listed in Restore.env will be replayed.
· If no log files exist in the running storage group log folder, then recovery will complete successfully using only the log file(s) listed in Restore.env.
If a database has been victimized, transaction logs will be replayed as follows:
· The sequence of log files listed in the Restore.env file will be replayed first.
· If additional log files exist in the Restore.env location, and they match and are contiguous with the logs listed in Restore.env, then they will also be replayed.
· Additional log files in the running storage group log folder will not be replayed.
If a database has been restored to a Recovery Storage Group (RSG), transaction logs will be replayed as follows:
· Any other databases in the RSG must be dismounted before beginning any transaction log file replay.
· The sequence of log files listed in the Restore.env file will be replayed first.
· If additional matching log files exist in the running log folder for the RSG, and they are in contiguous sequence with the files listed in Restore.env, they will be replayed.
· If additional log files exist in the Restore.env location, they will not be replayed under any circumstances.
Important After hard recovery succeeds, all files in the temporary directory (where Restore.env was created) are deleted. Never place your only copy of a log file in the Restore.env temporary folder.
Command line syntax
This is the command line reference that can be seen by typing Eseutil ./? at the command prompt in the Exchsrvr\Bin folder, and then selecting C for restore.
RESTORE:
DESCRIPTION: Restore information and completion.
SYNTAX: ESEUTIL /c[mode-modifier] <path name> [options]
PARAMETERS: [mode-modifier] - a letter designating the type of operation
to be done
m - dump Restore.Env
c - start recovery for a Restore.Env
<path name> - directory of the restore
(Restore.Env location)
OPTIONS: zero or more of the following switches, separated by a space:
/t[instance] - name of the instance containing the log
files to play forward, or if [instance] is
not specified, don't play forward any log
files unless they are in the restore
directory (default: use instance specified
by Restore.Env)
/f<path name> - directory containing the log files to play
forward (note: doesn't work with /t)
/k - preserves the log files used for recovery
/8 - set 8k database page size (default: 4k)
/o - suppress logo
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
Recovery refers to the process of playing transaction log files into a database. There are two kinds of recovery:
· Hard recovery: A transaction log replay process that occurs after restoring a database from an online backup.
· Soft recovery: A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file backup copy of a database.
For more information about hard and soft recoveries, see "Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003" (http://go.microsoft.com/fwlink/?linkid=68147).
For more information about instructions for running Eseutil in recovery mode, see How to Run Eseutil /R in Recovery Mode.
Hard Recovery
Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery is done. Hard recovery can be done with Eseutil by using the Restore mode (/C).
Soft Recovery
In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.
Exchange writes completed transactions to the database files found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.
Important:
A fundamental assumption of the soft recovery process is that no database or log files have been moved, deleted, or destroyed by the failure—or by the administrator after the failure.
Version Differences
Eseutil is always being improved, and added to from version to version. There are currently three major versions of Eseutil /R for each of the 3 major exchange versions as follows:
· Exchange Server version 5.5
· Exchange 2000 Server
· Exchange Server 2003
Exchange Server 5.5
The command line syntax for soft recovery with Eseutil in Microsoft® Exchange 2000 Server and Microsoft® Exchange Server 2003 is different from that used in Exchange 5.5. The rules and best practices for performing manual soft recovery with Eseutil have also changed.
· In Exchange 5.5, there is almost never a good reason to perform soft recovery with Eseutil. Each time the Information Store starts, soft recovery is run automatically, and correctly. In Exchange 5.5, the Eseutil soft recovery function was intended mostly for test environments where you might wish to recover a database on a server that did not have Exchange installed.
· There is a major risk in running Eseutil /R in Exchange 5.5: After restoring an online backup, running soft recovery instead will usually corrupt the database. An online backup needs hard recovery, not soft recovery.
· Only if the following two conditions are both met is it safe to run soft recovery instead of hard recovery in Exchange 5.5 and previous versions:
· The database paths have not changed since the backup was done.
· The .pat files from the online backup set are exactly 8 K in size (meaning, that they are composed of only two header pages, and have no actual database pages in them).
In all other circumstances, running soft recovery instead of hard recovery will corrupt the database in proportion to the size of the .pat files.
Note:
If you divide the byte size of a .pat file by 4096, and subtract two, that is the number of logically corrupt pages that will be in the database after improperly running soft recovery.
Exchange 2000 Server
In Exchange 2000, safeguards were implemented that always prevent soft recovery from running when hard recovery is needed.
There is another risk in running soft recovery with Eseutil. This risk still exists in Exchange 2000 or Exchange 2003: If you improperly specify paths to log files, to the checkpoint file or to database files, recovery may alter the database or log files and prevent recovery from being done again.
If existing transaction log files are not found by Eseutil when it tries to run recovery, it will create a new transaction log file, and try to attach the database to it. If the database is Inconsistent or in Dirty Shutdown state, the database will not be made startable. If the database is in a Consistent state, it will be attached and then detached from the new log file.
In either case, you risk making changes to the database or adding log files to the server that will result in the database becoming unstartable or that will confuse further recovery troubleshooting.
Note:
Just because recovery with Eseutil reports success does not mean that the database recovered is in a mountable state. Recovery succeeds whenever all available transaction log data that is currently available has been applied to the database files. Recovery success says nothing about whether the available data was sufficient to restore the databases to consistency.
In Exchange 5.5, you were almost always better off placing files in appropriate locations and then starting the Information Store to accomplish recovery. In Exchange 2003, there are two improvements to the Eseutil recovery functionality that provide important advantages over mounting a database to run recovery on it:
· Eseutil can force recovery to complete even if there is a missing database. This capability is also available in Exchange 2000.
· If a storage group is unexpectedly stopped, all databases running at the time will be Inconsistent in a Dirty Shutdown state. Suppose that the reason the storage group stopped was that a database drive suddenly failed, and the drive is inaccessible. In this case, you are missing one of the databases.
· If you run recovery while the database is missing, it is possible that you will alter the state of the transaction logs so that if the drive becomes accessible again, recovery will not complete successfully with that one database.
Note:
If you restore the database from backup, recovery will be able to complete successfully—this scenario only applies to recovering a database that was attached to the current log at the time of the sudden stop.
· If you know that the lost database will not be recovered, you can recover the rest of the databases in the storage group without first restoring the missing database from backup by using the Eseutil /I (ignore) switch.
Before using this switch to run recovery on the rest of the storage group, you should first make a backup of all transaction log files, including the current log (Enn.log). By keeping a copy of the current log and all the other logs, you will still be able to recover the missing database if it unexpectedly becomes available. Once you recover the rest of the databases, and thus write more information into Enn.log, you may not be able to recover the missing database using that log file.
Exchange Server 2003
Eseutil recovery can recover a database that has been moved to a different path location. This capability is available only in Exchange 2003.
Hard recovery has always been able to finish successfully, even if Exchange databases have been moved to different path locations since a backup was done. But until Exchange 2003, soft recovery could only work if the database files were in the same drive path as that defined in the transaction log files to be replayed.
In Exchange 2003, the /D switch was added to Recovery mode to allow override of the database path hard coded in the transaction log files. This new capability is very useful when restoring offline copies of databases to Recovery Storage Groups, or when recovering a "missing" database as described in the scenario above.
You can now copy a database and a group of transaction logs into any folder you desire, and successfully run soft recovery. Once the database is consistent, you can then move it to any other path desired, and attach it to a different log stream.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
Recovery refers to the process of playing transaction log files into a database. There are two kinds of recovery: Hard and Soft recovery. Hard recovery can be done with Eseutil by using the Restore mode (/C). For more information about understanding Eseutil recovery, see Eseutil /R Recovery Mode.
Command Line Syntax for Running Eseutil /R
To Run Eseutil /R
| · The basic command line syntax to run soft recovery with Eseutil is: ESEUTIL /R Enn · For example: ESEUTIL /R E00
The Enn specifies the log file prefix of the transaction logs you intend to play into the database. This command line will work only when run from the folder in which the transaction log files exist, and only when the databases to be recovered are in their original path locations. The log prefix specifier is a required parameter for Eseutil /R. |
Command Line Syntax for More Complex Recovery Scenarios
Transaction log files are not in the current folder
As a general rule, you should always run Eseutil /R from the folder where the transaction log files to be replayed exist. This is because the default soft recovery process looks in the transaction log files to find the path to the databases. If you run recovery from a folder where no log files exist, a new transaction log file will be generated, and this log file will not know where the databases are. If you wish to run recovery from outside the transaction logs folder, add this switch to the command:
/Lpath_to_logfiles
For example:
ESEUTIL /R E00 /Ld:\exchsrvr\logfiles
Controlling the checkpoint file
In most cases where you manually run soft recovery, you will want to either delete or hide the checkpoint file, because you will typically wish to replay all available transaction logs rather than start from the middle of an available sequence.
If you are running recovery from a folder where a valid checkpoint file exists, and you do not wish to have that file affect recovery, you must define a different path for a checkpoint file to be created during recovery. This might be required after restoring an offline backup into a storage group where databases are running
If you are running recovery from a different folder, and wish to use the checkpoint file to control recovery, you must point to the path for the checkpoint file.
If you wish to control the use of the checkpoint file during recovery, add this switch to the recovery command:
/Spath_to_or_away_from_current_checkpoint
For example:
ESEUTIL /R E00 /Sd:\
Recovering a storage group with a missing database
If a storage group is unexpectedly stopped, and one of the Inconsistent databases is removed or unavailable, you will be unable to mount any of the databases in the storage group until you restore the missing database or until you run manual recovery with the /I switch.
Important:
Before recovering while ignoring the missing database, you should make a backup copy of all transaction log files, including the current log file (Enn.log). Once Enn.log has been changed by recovering the other databases, it may not be useable for recovering the missing database if it is once again made available.
Recovering a database "out of place"
This method of recovery completely isolates the recovery process from the running storage group. It is also the way you should recover an offline backup in a Recovery Storage Group, if you intend to play any log files into the backup.
To prepare to do this, you should move the database files (.edb and .stm) and all transaction logs you intend to play into a single temporary folder.
To run Eseutil out of place
| · From this folder, you can run the following command: ESEUTIL /R Enn /I /D · For example: ESEUTIL /R E00 /I /D |
The /I switch may or may not be necessary, depending on whether there are Clean Shutdown records in the transaction logs for other databases that were attached to the logs. Using the switch in this circumstance is recommended so that you do not have to start recovery again if there is a "hanging attachment" somewhere in a log file.
The behavior of the /D switch deserves more explanation. If the /D switch is not present at all, then the database paths recorded in the transaction log files will be used to locate the databases. This is the only behavior available in Eseutil for Exchange 2000 and previous versions. If the /D switch is used without a path, then the current directory will be used as the path for the database files. If the /D switch is immediately followed (with no intervening space) by a file path, then that path will be used to locate the database files. For more information about using the /D switch to resolve issues with transaction logs while moving an Exchange database, see Issues with Transaction Log Files When Moving an Exchange Mailbox Database.
Because of the possibility of typing errors, it is strongly recommended that you eliminate the need for using paths with Eseutil switches by running Eseutil from a folder where all data files already exist.
After recovery finishes and the database files are in Clean Shutdown state, they may be moved into place in the appropriate storage group, and attached to the log files there by mounting the databases.
Note:
It will usually be necessary to mark the checkbox for "This database can be overwritten by a restore" on the database object properties in Exchange System Manager before the database will mount.
Command line reference
This is the command line reference that can be seen by typing eseutil ./? at the command prompt in the Exchsrvr\Bin folder, and the selecting R for restore.
RECOVERY:
DESCRIPTION: Performs recovery, bringing all databases to a
clean-shutdown state.
SYNTAX: ESEUTIL /r <3-character logfile base name> [options]
OPTIONS: zero or more of the following switches, separated by a space:
/l<path> - location of log files
(default: current directory)
/s<path> - location of system files (eg. checkpoint file)
(default: current directory)
/i - ignore mismatched/missing database attachments
/t - on successful recovery, truncate log files
/u[log] - stop recovery when the Undo phase is reached with the option
to stop when a certain log generation is recovered.
[log] is the log generation number and if not specified
the replay will go to the end of the existing logs.
/d[path] - location of database files, or current directory
if [path] not specified (default: directory
originally logged in log files)
/n<path1[:path2]> - new location of database file and optional old location
if the database file location changed.
Can be specified for each database file.
If a certain database is not in the list,it won't get recovered.
To allow recovery in the original location
for all other database, use /n*.
(not valid with /d switch, not valid with
/b switch)
/8 - set 8k database page size (default: 4k)
/o - suppress logo
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
Eseutil /G integrity mode, is a reliable way to verify whether or not an Exchange Server database contains specific inconsistencies. Using this tool to test database integrity is a safe approach because the check is performed in a read-only mode. It is important to detect specific type of anomalies or inconsistencies in order to take proper steps to fix the database. You should recover the database to Clean Shutdown state before running an integrity check.
For more information about doing an integrity check using Eseutil, see How to Run Eseutil /G in Integrity Mode.
Other Exchange Versions
In Exchange Server version 5.5, when the Exchange Database Engine (ESE) encounters a read verification failure (Error -1018 (JET_errReadVerifyFailure)) during an Eseutil integrity check, the engine will not perform retry operations. If ESE tries to read the page after the initial failure, then the length of time to run the Eseutil function dramatically increases. In Exchange Server 5.5 Service Pack 2 (SP2), the ESE will try to successfully read the page up to a maximum of 16 times.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
The integrity check in Eseutil is basically a test run of the repair function. Problems that repair would address will be reported in the <database>.integ.raw file. The .raw file logs results for all tables in the database, not just ones that have problems. For more information about the Eseutil integrity mode, see Eseutil /G Integrity Mode.
Note:
An integrity check may end prematurely if damage to the database is of such a nature that parts of the database must be repaired before other parts can be checked. The fact that an integrity check ends before it finishes does not necessarily mean that repair is unlikely to succeed. Although you can perform an integrity check after a dirty shutdown, we do not recommend this. You should recover the database to Clean Shutdown state before you run an integrity check if you can do so.
Procedure
To run Eseutil /G
| · The basic command line syntax to run an integrity check with Eseutil is: ESEUTIL /G database_filename.edb For example: ESEUTIL /G priv1.edb
There must be disk space available to the equivalent of 25 percent of combined size of the Exchange database (.edb) and streaming database (.stm) files. The streaming database must be in the same folder as the .edb file. |
You may be faced with the following scenarios when you run an Eseutil /G integrity check on the database:
· Insufficient local drive space for temporary database
· Ignoring streaming database mismatches
Insufficient Local Drive Space for Temporary Database
Many of the integrity checks involve reconstructing indexes and other data inside a temporary database. Afterward, a comparison is done between the two databases.
If you do not have free disk space equivalent to 20 percent of the size of the files being checked, then there is greater likelihood of running out of disk space during the check. You can add this switch to the command to redirect the "scratchpad" database to a drive with more space:
/Tpath_to_temporary_database
For example:
ESEUTIL /G priv1.edb /T\\Server2\d$\scratchpad.edb
Note:
There is no space between the /T switch and the path specification. You can also use an ordinary drive letter path specification if desired.
Ignoring Streaming Database Mismatches
Exchange will detect whether a database and its streaming database are synchronized with each other. If they are not in synch, you can ignore the problem and force an integrity check to proceed regardless, by using the /I switch. For example:
ESEUTIL /G priv1.edb /I
If there are no SLV files (.stm or streaming database files) checksum errors reported in the .raw file output, then while the two files may be formally out of synch, the likelihood of successful repair and reintegration of the streaming file data is high.
Command line reference
The following is the command line reference that can be obtained by running Eseutil /? and then G from the Exchsrvr\bin folder:
INTEGRITY:
DESCRIPTION: Verifies integrity of a database.
SYNTAX: ESEUTIL /g <database name> [options]
PARAMETERS: <database name> - filename of database to verify
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name (default: TEMPINTEG*.EDB)
/f<name> - set prefix to use for name of report files
(default: <database>.integ.raw)
/i - bypass the database and streaming file mismatch er
ror
/8 - set 8k database page size (default: auto-detect)
/o - suppress logo
NOTES: 1) Integrity-check does not run database recovery. If a
database is in a "Dirty Shutdown" state it is strongly
recommended that before proceeding with an integrity-
check, recovery is first run to properly complete
database operations for the previous shutdown.
2) The /i option ignores the signature mismatch error if
the database and streaming file do not match each other.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
While the Eseutil file dump mode is often overlooked by administrators, it is an invaluable troubleshooting and diagnostic tool. This mode does not repair or make other changes to files. Its purpose is to provide you with information about the state of the database files. For example, to see if your database has been repaired by using the Eseutil /P command, dump the header using one of the following commands for the private information store:
ESEUTIL /mh x:\exchsrvr\mdbdata\priv.edb |more
-or-
ESEUTIL /mh x:\exchsrvr\mdbdata\pub.edb |more
In file dump mode, you can:
· View header information for the database, streaming database, checkpoint and transaction log files.
· View header information for individual database pages.
· Validate that a series of transaction log files forms a matched set and that all files are undamaged.
· View space allocation inside the database and streaming database files.
· View metadata for all tables or for a specific table in the database file.
For more information about syntax and about running Eseutil /M in different scenarios, see How to Run Eseutil /M in File Dump Mode.
The following table provides details of switches used to view headers of different types of database files:
| You can use the | To |
| Eseutil /mh switch | View the header information of Exchange database files (.edb), streaming files (.stm) and Patch files (.pat) for a private or public information store. Note Patch files only exist on pre-Service Pack 2 (SP2) Exchange 2000 Server-based servers. |
| Eseutil /ml switch | View the header of a private information store log file. |
| Eseutil /mk switch | View the header information for private information store checkpoint files. |
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
For more information about /ml and /mh switches, see Eseutil.exe Examples.
You can use the /m switch with Eseutil to create a file dump, or formatted output of various database file types that you specify when you run Eseutil.
The syntax for Eseutil /m is:
ESEUTIL /m mode-modifier file_name [options]
The most common mode modifiers that are used with Eseutil are:
· h - dump database header (default)
· k - dump checkpoint file
· l - dump log file or set of logs
Note:
To list additional options for Eseutil, type eseutil /? at a command prompt, and then press ENTER.
For more information about Eseutil file dump mode, see Eseutil /M File Dump Mode.
How to Run Eseutil /M
You can run Eseutil in file dump mode to do the following:
· View transaction log file and database page headers
· Validate transaction log files
· Check metadata and space usage
View file and page headers
The header for checkpoint, transaction log and database files is the first physical page of each file. Some files have a "shadow" header—a copy of the header on the second page of the file. The file header contains important state and diagnostic information about the file. By correlating header information from various files, you can determine whether the files belong together or are mismatched.
There are separate switches for viewing different kinds of file headers. Be sure that you use the correct switch with the correct file type, or the output will be invalid.
To view the header of database files and page headers
| · To view the header of a database, streaming database file or online backup patch file: ESEUTIL /MH {filename.edb | filename.stm | filename.pat} · To view the header of a checkpoint file: ESEUTIL /MK filename.chk · To view the header of a transaction log file: ESEUTIL /ML filename.log · To view the header of a database page: ESEUTIL /M database_filename.edb /Plogical_page_number
There is no space between /P and the page number. |
Validate transaction log files
Prior to Exchange 2000, it was necessary to closely check a set of transaction log files to determine:
· If they were all from the same sequence
· If there were any gaps in the sequence of logs.
· Doing this required examining and comparing each file header. There was no way to verify that a transaction log file was undamaged. Transaction log files in Exchange 5.5 were not checksummed.
Starting with Exchange 2000 Server, you can use the /ml switch to verify both the sequence and the integrity of a set of log files.
To verify both sequence and integrity of a set of log files
| · Run the following command syntax: ESEUTIL /ML Enn For example: ESEUTIL /ML E00
By specifying only the log file prefix, rather than a particular log file name, all log files in the current folder will be scanned and validated. You must run this command from the folder where the log files exist. Processing each log file will take a few seconds. To process the current log file in a running storage group, all databases in the storage group must be dismounted. |
Check metadata and space usage
The output of the metadata and space usage commands is very similar to each other. A space usage dump is a metadata dump with columns added for space usage and streaming databases statistics. A metadata dump will be faster to complete than a space usage dump. Therefore, use the metadata dump when you are looking for table information such as pgnoFDP and objidFDP values, and you are not concerned about space usage.
To view metadata dump
| · Run this basic command syntax to display metadata information for a database: ESEUTIL /MM database_filename.edb You can also display data for a single table by specifying the name of the table. For example, you may wish to view the Msg or attachments table: ESEUTIL /MM database_filename.edb /t1-23
The attachments table in an Exchange 200x database is table 1-23.
The space usage dump syntax is identical to that for metadata, except that the switch /MS is used instead of /MM. |
An aggregate total of the free pages in the database is listed on the last line of a space usage dump. You can multiply this number by the page size for the database to get an approximation of the space that will likely be reclaimed by defragmentation.
Notes:
· In a typical database, the metadata dump will take multiple screens. To preserve the output to a file, add a redirection command to the end of your command line, for example:
· ESEUTIL /MM database_filename.edb > filename.txt
Command line reference
The following is the command line reference that can be obtained by running Eseutil /? and then M from the Exchsrvr\bin folder:
FILE DUMP:
DESCRIPTION: Generates formatted output of various database file types.
SYNTAX: ESEUTIL /m[mode-modifier] <filename> [options]
PARAMETERS: [mode-modifier] - an optional letter designating the type of
file dump to perform. Valid values are:
h - dump database header (default)
k - dump checkpoint file
l - dump log file or set of logs
m - dump meta-data
s - dump space usage
u - dump undefined codepoint fixup table
<filename> - name of file to dump. The type of the
specified file should match the dump type
being requested (eg. if using /mh, then
<filename> must be the name of a database)
OPTIONS: zero or more of the following switches, separated by a space
/p<pgno> - dump the specified page from the database
/s<file> - set streaming file name (default: NONE)
/t<table> - perform dump for specified table only
/v - verbose
/8 - set 8k database page size (default: auto-detect
/o - suppress logo
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
For more information about /ml and /mh switches, see Eseutil.exe Examples.
The Eseutil tool in Microsoft® Exchange Server 2003 includes a /K switch that you can use to verify the page-level integrity of the information store databases. The /K switch can be used to detect file header damage. File header damage may occur in databases, log files, patch files, or checkpoint files. In addition, you can use the Eseutil /K command to verify the checksum integrity of the transaction logs when all the databases in the storage group are dismounted.
Note:
The checksum mode does not run a database recovery. If a database is inconsistent or is in a "dirty shutdown" state, Microsoft recommends that you perform a recovery operation to make sure that the database operations are completed correctly. After you perform the recovery operation, you can use the Eseutil tool to perform the integrity check.
For more information about running Eseutil in checksum mode, see How to Run Eseutil /K in Checksum Mode.
With the inclusion of ESEFile features in Eseutil, the checksumming capabilities of Eseutil are extended to include streaming databases, log files, and checkpoint files. Note the following uses of the Eseutil /K checksum command:
· If you checksum only a streaming database, only the header pages in the database will be checked. The data is ignored. If you wish to checksum an entire streaming database, you must run checksum mode against the Exchange Database (.edb) file. The reason for this is that the checksums for data in the streaming file are not actually stored in the streaming file, but in a table in the .edb file.
· The Eseutil checksum mode will not allow you to checksum individual pages in the database. But you can use the page dump mode to determine whether the checksum on any given page is correct.
Previous Exchange Versions
Prior to Exchange 2003, a database could be checksummed during online backup, by running Eseutil /G, or by using the ESEFile utility. Eseutil replaces the Microsoft Exchange 2000 Server and Exchange Server 5.5 ESEFile support utility.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
This section explains how the Eseutil /K checksum mode works on Exchange Server 2003 databases, and covers basic operation procedures. Exchange 2003 uses a checksum procedure, by using the /K switch, to confirm the data integrity of pages in the database. You can also use the switch to perform a checksum procedure on a streaming file. For more information about how to use Eseutil in checksum mode, see Eseutil /K Checksum Mode.
Before You Begin
Important:
Before you use the Eseutil tool, use Exchange System Manager to dismount the stores that you want to examine.
The checksum feature does not run a database recovery. If a database is inconsistent, or in a "dirty shutdown" state, we recommend that you perform a recovery operation to make sure that database operations are completed correctly. After you perform the recovery operation, you can use the Eseutil utility to perform the integrity check.
Procedure
To do a Eseutil /K checksum with basic syntax
| · Enter this basic syntax at the command line to checksum an ESE database, streaming database, transaction log, or checkpoint file: ESEUTIL /K <filename>
Replace <filename> with the path and name of the file that you want to checksum |
The following optional command-line switches are associated with the /K switch:
· /s<filename> Use this switch to specify the streaming file name. The default setting is none.
· /t<db> Use this switch to specify the temporary database name. The default name is Tempchksum*.edb.
· /e Use this switch if you do not want to perform a checksum procedure on the database file.
· /i Use this switch if you do not want to perform a checksum procedure on the streaming file.
· /o Use this switch to suppress the Microsoft logo.
To use Eseutil to checksum only the .EDB or .STM file
| 1. Click Start, and then click Run. 2. In the Open box, type cmd, and then click OK 3. Switch to the C:\Program Files\ExchSrvr\Bin folder, type one of the following commands (as appropriate for your situation), and then press Enter: · To check the integrity of the public information store database: ESEUTIL /K "c:\program files\exchsrvr\mdbdata\pub1.stm" · To check the integrity of the private information store database: ESEUTIL /K "c:\program files\exchsrvr\mdbdata\priv1.stm" |
If you want to save time by checksumming only the files in question, you can use the /E (ignore EDB) or /I (ignore stm) switches. If you use the /E switch, the checksum table for the streaming database is read from the edb file, but no other edb file pages are checksummed. Using the .stm file name in checksum mode will checksum only the first two header pages of the streaming database. For example:
ESEUTIL /K priv1.edb /E (checksums stm file only)
ESEUTIL /K priv1.edb /I (checksums edb file only)
ESEUTIL /K priv1.stm (checksums stm header pages only)
Note You cannot checksum the whole streaming file unless the database files are in a Clean Shutdown state. This is because the table storing the checksums in the streaming file is in the edb file. If the database is not in Clean Shutdown state, you cannot know for sure that this table is completely up to date and valid.
Command line syntax
The following is the command line reference that can be obtained by running eseutil /? and then K from the Exchsrvr\bin folder:
CHECKSUM:
DESCRIPTION: Verifies the checksums of a database, streaming file,
checkpoint file, or log file (or set of log files).
SYNTAX: ESEUTIL /k <file name> [options]
PARAMETERS: <file name> - file name to verify
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name (default: TEMPCHKSUM*.EDB)
/p<x> - add artificial 1 second pause once every x I/O's
(default: no pause)
/e - don't checksum database file
/i - don't checksum streaming file
/8 - set 8k database page size (default: auto-detect)
/o - suppress logo
NOTES: 1) This operation does not run database recovery. If
the database file (.edb) is in a "Dirty Shutdown"
state it is not possible to verify checksums in the
streaming file (.stm).
2) If the file is not a database file, the options are
ignored.
3) If the file is a streaming file, only the header is
verified and not the data pages.
4) The pause (/p) option is provided as a throttling
mechanism. It only applies when verifying checksums
of a database file.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
The ability of Eseutil to copy large files is a new capability introduced in Exchange Server 2003 that has been imported from ESEFile. The copy file mode is optimized to copy very large files efficiently. You can use the switch to copy a database, streaming file, or log file. However, the mode is not suited as a general purpose copy utility.
Note:
Since copy file mode does not accept wildcard file specifications, you must fully specify a file name and copy one file at a time.
Depending on disk and network conditions, copy file mode may be able to copy a file up to 20 percent faster than a typical copy. It can also handle copying of very large files that previous versions of Microsoft® Windows 2000 Service Pack 2 (SP2) would not copy.
For more information about how to run Eseutil in copy file mode, see How to Run Eseutil /Y in Copy File Mode.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
You can use the Eseutil /Y switch to copy a database, streaming file, or log file. For best speed and stability, you should run Eseutil /Y from a local command prompt on the copy destination server rather than from an intermediate location. For more information about understanding the Eseutil copy file mode, see Eseutil /Y Copy File Mode.
Procedure
To run the Eseutil /Y command
| 1. Type the syntax (as in examples below) at the local command prompt in the destinationfolder. · The following is an example of how to copy the priv1.edb file from server1 to your current location: ESEUTIL /Y \\server1\d$\priv1.edb · The following is an example of how to copy the priv1.edb file from sever1 to server2 specifying the full path and file names for both source and destination: ESEUTIL /Y \\server1\d$\priv1.edb /D\\server2\d$\priv1.edb
Unlike the default copy command, you must use the /D switch when you specify the destination location. |
Command Line Syntax
The following is the command line reference that can be obtained by running Eseutil /? and "Y" from the Exchsrvr\bin folder:
COPY FILE:
DESCRIPTION: Copies a database, streaming file, or log file.
SYNTAX: ESEUTIL /y <source file> [options]
PARAMETERS: <source file> - name of file to copy
OPTIONS: zero or more of the following switches, separated by a space:
/d<file> - destination file (default: copy source file to current directory)
/o - suppress logo
NOTES: 1) If performed on arbitrary files, this operation may fail at the end of the file if its size is not sector-aligned.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
· Reference for Common Eseutil Errors
This section explains the structure of a database and discusses database recovery strategies.
Understanding Database Structure
To understand how a database is structured you should understand page levels, Exchange Store Engine (ESE) table levels, and application levels of a database. The following is a quick description of each level:
Page level: The file contains an ordered series of pages (typically 4 kilobyte or a multiple of 4 kilobytes), with each page sharing a common organizational structure. Each page has page header information and page data. The header information includes the checksums for the page that enable Exchange to verify data integrity and to correct single-bit errors on the page.
ESE Table level: Groups of pages are owned by tables that are managed by the ESE database engine. A typical Exchange database contains thousands of individual tables.
Application level: ESE is a general purpose database that can be used by different applications. For example, both Exchange and Active Directory directory service use ESE. The ESE database engine stores information in its tables as directed by a particular application. ESE itself does not understand the application-defined relationships between tables or the meaning of the data stored in each table.
Understanding Database Recovery Strategies
The most basic strategy for recovering from database file damage is to restore a known good copy of the database from backup and to roll the database forward using subsequently generated transaction log files. To use this strategy, the following three assumptions must apply:
· You have a good backup of the database.
· All transaction log files generated since the backup are available and undamaged.
· The problem in the database is not caused by a logical corruption or unintended deletion. For example, if a virus scanner was to corrupt messages or delete them, then the corruptions and deletions would be part of the transaction log record and would be replayed into the database after restoration from backup.
Other database recovery strategies are described below.
Move Mailboxes
When you move an Exchange mailbox to a different database, the contents of the mailbox are processed by the Exchange Information Store just as when they were created. Items that have been damaged will be skipped. Therefore, moving all mailboxes to a new database is an excellent strategy for removing damaged items while at the same time maximizing the amount of salvaged user content.
After a mailbox has been moved, Outlook client profiles will be automatically updated to point clients to the new database or server. For this to occur, the previous server must remain online with its Information Store service that is running until after all clients have logged on one time and have been redirected. If the previous server is not kept online, then Outlook client profiles must be updated manually or through scripts.
Previous offline or cached mode client files will continue to work after a mailbox has been moved. Client rule functionality is also preserved when a mailbox is moved.
Moving a mailbox has the same effect on the destination server as redelivering all the items in the mailbox at one time. Therefore, if you are moving many mailboxes, it is best to do the operation at off-peak times, and to provide clients information in advance about when the move will occur and about how to receive help if they experience problems logging on after the move.
Moving many mailboxes will cause a larger than ordinary number of database transaction log files to be generated for the destination database. You should closely monitor transaction log disk space on the destination server during a bulk mailbox move operation. If you are close to running out of transaction log disk space, you can run an online full or incremental backup to clear the log files or enable circular logging before the move and then disable circular logging right after the move.
Moving all mailboxes to a new database, and discarding the previous database, maximizes the preservation of salvageable user content while at the same time minimizing database downtime.
For information about how to move an Exchange database to another server or storage group, see Moving an Exchange Mailbox Database to Another Server or Storage Group.
Repair the Database
Generally, you should repair a database only when it is infeasible to restore the database and roll it forward. Frequently, repairing a database will take more time than restoring from backup.
Note If the database is severely damaged, repair will take longer to run, and the probability of a successful repair is less likely. If you run repair on an undamaged or only slightly damaged database using typical enterprise-class server hardware, the process will usually take about an hour for every 5 GB of data. If you are calculating repair times as part of designing Service Level Agreements (SLAs), you should perform your own benchmarks on a typical database running on hardware similar to that used for Exchange in your organization. If a database has been severely damaged, repair times may increase by a factor of 10 or more.
For more information about how to use Eseutil to repair a database, see Eseutil /P Repair Mode.
Restore, Repair, and Merge
Restoring, repairing, and merging a database is frequently called a hybrid strategy. It can be used when you have a good backup of the database, but do not have all the transaction logs created after the backup.
In this case, you can restore the backup, and in parallel, repair the damaged copy of the database in a Recovery Storage Group on the same server or on a laboratory server. You can then use the Recovery Storage Group feature to mount both copies of the database separately and merge data from the repaired database to the restored database.
Assuming the repair is successful, this strategy has a chance of recovering almost as much data as if you had been able to use the transaction logs. For more information about several hybrid strategies using Recovery Storage Groups, see the guide on Using Exchange Server 2003 Recovery Storage Groups (http://go.microsoft.com/fwlink/?LinkId=47589).
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Reference for Common Eseutil Errors
This section covers common Extensible Storage Engine (ESE) errors encountered when running Eseutil on your information store database files, transaction log files, and streaming files.
Error Codes, Descriptions
The table below describes some of the common database errors encountered when running Eseutil.
| Error number | JET Error | Error Description |
| Error -327 (0xfffffeb9) | JET_errBadPageLink | This error occurs when there is logical corruption in the database. Logical corruption can be caused by a bug in Exchange or by a hard disk crash. A crash can cause the error if write ordering of pages from cache was not preserved, and therefore only some pages from a transaction were updated while other pages were left as older versions. |
| Error -501 (0xfffffe0b) | JET_errLogFileCorrupt | This error indicates physical damage to a transaction log file. It is similar in its causes and effects to an error -1018 in a database file. You cannot repair or recover a log file after this error occurs. |
| Error -510 (0xfffffe02) | JET_errLogWriteFail | This error indicates that Exchange was unable to write to the current log file. The log disk may be full, a hardware error may have made the disk inaccessible or another process may have locked the log file. |
| Error -514 (0xfffffdfe) | JET_errBadLogVersion | This error occurs when trying to replay a log file that was generated with a different version of Exchange. This error may occur after upgrading to a major version of Exchange, and occasionally may happen after a service pack or hotfix upgrade that alters the database schema or internals. Service packs that can trigger this error include Exchange 2000 Server Service Pack 1 (SP1) or Service Pack 2 (SP2), Exchange Server 2003 SP1, and Exchange Server 5.5 Service Pack 4 (SP4). |
| Error -515 (0xfffffdfd) | JET_errInvalidLogSequence | This error indicates that a log file is missing or does not match the other log files. This can happen if the log signature does not match, if the creation time does not dovetail with other logs in the sequence or if another problem is detected which indicates this log was not part of the original sequence. This error is seen most often because a log file is missing. It may also be seen in circumstances where multiple restorations of a database have left you with multiple log streams for that database, and you have tried to blend the log streams. |
| Error -519 (0xfffffdf9) | JET_errLogSequenceEnd | Exchange Server 2003 and earlier versions support log file sequences of up to 1,000,000 log files per storage group before the log sequence must be reset to one. Database behavior, after this limit is reached, varies by Exchange version. For more information about resolving this error for Exchange 2000 and Exchange 2003, see the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used." |
| Error -530 (0xfffffdee) | JET_errBadLogSignature | This error indicates a signature mismatch. The signature is actually "good" but it does not match other log files in the sequence or does not match the log signature recorded in the database. This could be because log files from different sequences have been found or that a database has crashed and the logs needed to recover it are no longer present. |
| Error -531 (0xfffffded) | JET_errBadDbSignature | This error is similar to error -530. Both databases and log files have signatures that identify and match them to each other. It is not necessary in all cases that the signatures match, but when a signature mismatch affects recovery, either error -531, -530 or both will be seen. In some cases, recovery can complete successfully after Error -531, but its presence indicates that transaction log data was not able to be applied to the database. |
| Error -532 (0xfffffdec) | JET_errBadCheckpointSignature | This error indicates that the checkpoint file does not match the transaction log files. Removing the checkpoint file will correct this error. It will also cause Exchange to re-scan every transaction log to determine whether it is needed for recovery. If there are thousands of log files, this may take several minutes or more. |
| Error -533 (0xfffffdeb) | JET_errCheckpointCorrupt | This error indicates that a corrupt checkpoint file has been deleted. In most versions of Exchange, a corrupt checkpoint file will be automatically deleted and re-created. A corrupt checkpoint file may be deleted because it cannot be used. |
| Error -537 (0xfffffde7) | JET_errBadSLVSignature | This error indicates that the current .edb file and .stm file do not match each other. An Exchange 2000 Server database or Exchange Server 2003 database consists of two files--the .edb MAPI database file and the .stm streaming database file. These files must be kept synchronized with each other, and they cannot be used with other databases. |
| Error -540 (0xfffffde4) | JET_errDatabaseStreamingFileMismatch | For more information, see Error -537. |
| Error -543 (0xfffffde1) | JET_errRequiredLogFilesMissing | This error indicates that log files are missing. An Exchange database that has been shut down correctly is in a Clean Shutdown space and has detached from its log files. The database is now independent of the log files. All existing log files could be deleted and the database could be restarted with a new or different set of log files.
Deleting log files for a Clean Shutdown database will affect the validity and roll forward capabilities of previous backups If a database has not been shut down correctly, it is still attached to one or more of the log files. These log files are required to bring the database to a consistent state. If these log files cannot be made available, the database must be restored from backup or repaired before it can be started again. |
| Error -544 (0xfffffde0) | JET_errSoftRecoveryOnBackupDatabase | This error indicates that in place of hard recovery, a soft recovery was performed on the database. If a database is restored from a streaming online backup, it is in a special state that requires "hard recovery," as contrasted to "soft recovery" which runs after an ordinary database crash. Hard recovery is run by triggering transaction log replay within the backup application or by running Eseutil /CC after database and transaction log files have been restored. For more information about running hard recovery, see Eseutil /C Restore Mode. |
| Error -548 (0xfffffddc) | JET_errLogSequenceEndDatabasesConsistent | This error may accompany error -519, and indicates that no more transaction log files can be generated in this sequence, but databases are all in Clean Shutdown mode. This means it is safe to remove transaction log files and reset the log sequence. For more information about resolving this error for Exchange 2000 and Exchange 2003, see the Microsoft Knowledge Base article 830408, "Exchange database stores remain mounted although all transaction logs that are available to a storage group have been used." |
| Error -549 (0xfffffddb) | JET_errStreamingDataNotLogged | This error occurs when circular logging is enabled and data placed in the streaming database (.stm file) is not logged. Circular logging causes log files to be deleted soon after their data has been written to the database file. This reduces disk space requirements for transaction logging, but also prevents rolling the database forward from a backup. By default, circular logging is disabled, and the online backup process is relied on to remove excess transaction logs that are no longer required for rolling the database forward. If you change circular logging settings, you should immediately perform a full backup. |
| Error -550 (0xfffffdda) | JET_errDatabaseInconsistent | This error will occur if transaction log files are missing or not all data from the log files could be applied to the database. If a database is unexpectedly stopped, it will be in Dirty Shutdown state. (The state of a database can be viewed by reading the database header while the database is stopped. For more information, see section on Eseutil /M File Dump Mode). A database in Dirty Shutdown state is still attached to its transaction log files and must have required log files applied to it before it can be started. To correct this error, you must apply all required log files, restore the database, or repair the database. |
| Error -551 (0xfffffdd9) | JET_errConsistentTimeMismatch | This error is closely related to error -1216 (JET_errAttachedDatabaseMismatch). It is typically caused by restoring raw copies of one database's files while other databases in the storage group are in a Dirty Shutdown state. For more information about resolving the error for Exchange Server 2000, see the Microsoft Knowledge base article 296843 "How to recover an Exchange 2000 Server database after error -1216." |
| Error -552 (0xfffffdd8) | JET_errDatabasePatchFileMismatch | This error can occur in versions of Exchange prior to Exchange 2000 Server Service Pack 2 (SP2) after restoring from a streaming online backup. The patch file is a file used in transaction log replay for older versions of Exchange. Optimizations in Service Pack 2 for Exchange 2000 allow hard recovery to proceed without patch data. |
| Error -1216 (0xfffffb40 | JET_errAttachedDatabaseMismatch | This error is closely related to error -551 (JET_errConsistentTimeMismatch). It typically occurs after a simultaneous crash of all databases in a storage group if one of the databases is no longer available (for example, because its disk has been destroyed). For more information about resolving the error for Exchange 2000 Server, see the Microsoft Knowledge base article 296843 "How to recover an Exchange 2000 Server database after error -1216." |
| Error -1206 | JET_errDatabaseCorrupted | This is a generic error and does not necessarily indicate a severe problem. The error will trigger at the end of an integrity check where problems of mild to medium severity have been found. Scan the <database>.integ.raw file for the word ERROR to get detailed information about issues found in the database. For more information, see the Events & Errors Message Center. For more information on resolving the error for Exchange 2000 Server Standard Edition, see Microsoft Knowledge Base article, 313704 "XADM: Running an Integrity Check on the Srs.EDB Database Always Returns a JET_errDatabaseCorrupted Error Message." |
| Error -939586631 (Unknown Error, Unknown Error) | Unknown Error | This error occurs when you try to run Eseutil /CC with an incorrect path to the Restore.env file. The mailbox store will fail to mount as a result of this error. You can resolve the issue by running Eseutil /CC with the correct path of the Restore.env file. If the issue persists, you can run Eseutil /P followed by Eseutil /D, and then try running Eseutil /CC again to recover the database. For more information about running Eseutil /CC, see How to Run Eseutil /C (Restore) in Different Scenarios. |
For More Information
For more information about these error codes, see
· Microsoft Knowledge Base article 266361, "Extensible Storage Engine 98 Error Codes 0 to -1048"
· Extensible Storage Engine Error Codes
For more information about understanding Extensible Storage Engine (ESE) file types, see Extensible Storage Engine Files.
For more information, see the following topics in the Exchange Server Database Utility Guide:
· Eseutil /D Defragmentation Mode
· Database Recovery Strategies
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync, ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN, Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile, Windows NT, and Windows Server System are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.
Posts
0 comments:
Post a Comment