ESEUTIL
Although an Extensible Storage Engine database can perform an online defragmentation, it does not reduce the physical size of the database. At times you can purge a large number of email messages to free memory. However, the database file size generally grows at a steady rate to a point at which the amount of data removed matches the amount of data added.
An offline defragmentation reduces the physical size of a database by writing data from the used pages to a new database created by ESEUTIL, the Extensible Storage Engine Utility. This utility defragments, repairs and checks the integrity of the Exchange Web Storage System. When ESEUTIL starts, it creates a new database and copies database records to it. It discards unused pages. The result is a compact database file. 
You should not perform a defragmentation across the network. By default, ESEUTIL prefers the contents of a live database to a temporary one. When you use the command, TEMPDFRG.edb and TEMPDFRG.stm, the temporary new database replaces the original. There are switches to control where the temporary database is created and whether the original database file is deleted. It is not recommended to locate the temporary files across the network. This will cause defrag to take longer and will slow down the network during that time.
After a defragmentation or repair is run, new database signatures are assigned. Because this is a new database, the database signature is changed; therefore previous transaction logs can no longer be replicated into this database. 
Using ESEUTIL
ESEUTIL is a database level utility that is not application specific. ESEUTIL extracts or dumps header information from database, checkpoint, and transaction log files to provide diagnostic information. The ability to dump file header information is especially useful when you want to check the current state of the database and transaction log files. You can use this information to discern why the database might not start, what transaction logs you need to replay or to which log file the Edb.chk file points. 
File Header Output 
By dumping file header information, there are several output lines that you can actually pull information from. One is DBSignature; this is used to match the database file (*.edb), stream file (*.stm), and transaction logs. The signatures used by ESE are created with a random number and the date stamp of when the signature was created. Another output line is State. This specifies whether a database is consistently shut down or not. A database restored from an online backup is always inconsistent whereas a database restored from an offline backup should always be consistent.
The Output of eseutil /mh will include the following pieces of detailed information, for example:
•	DB Signature: Create time:03/30/2000 18:17:00 Rand:68947200 Computer:
•	cbDbPage: 4096
•	State: Consistent
•	Scrub Date: 00/00/1900 00:00:00
•	Repair Date: 00/00/1900 00:00:00
•	Last Consistent: (0x16,F,159)  03/31/2000 12:11:46
•	Last Attach: (0x1,1404,17A)  03/31/2000 11:49:44
•	Last Detach: (0x16,F,159)  03/31/2000 12:11:46
•	Log Signature: Create time:03/30/2000 18:16:56 Rand:68924870 Computer:
•	OS Version: (5.0.2195 SP 0)
•	Previous Full Backup:
•	Current Incremental Backup:
Transaction Log File Headers 
To extract transaction log file header information, use ESEUTIL/ml and the transaction log. ESEUTIL/ml helps you determine why transaction logs don't play back into the database. For example, if you type ESEUTIL/ml edb00012.log, the output is the following parameters: 
•	L-generation log generation number in decimal
•	Signature transaction log file signature
•	Database location hard-coded into this file and cannot be changed except through the restore process
•	last-attach references the log file that was Edb.log the last time the Extensible Storage Engine started
These parameters produce three numbers. For example, if the number is: XXXYYYZZZ, then XXX is a transactional log file number, in decimal from; YYY is a page within the file and ZZZ is the byte set within the page.
Note   The term, Last Consistent, refers to the log file that was Edb.log at the last stop of the database. This gives the same three numbers as the last attach.
Repairing Damaged Databases 
The repair function of ESEUTIL examines the structure of the database tables and records broken links. The Extensible Storage Engine repair mode attempts to restore links but the process is slow and data loss is highly likely. You should only use this as a last resort. Running the repair function ESEUTIL/p attempts to restore the damaged database. The output looks somewhat like ESEUTIL/g, but the database is read/write. 
You might encounter physical damage to a database, where you receive -1018, -1019 or –1022 errors, the database page is removed, and data is lost. Any repair rewrites the database signature. You should also perform a full back up of the database. If you restore a backup made before the repair, then the database is rolled forward to the state it was in at the time of the repair. You cannot replay transaction logs that are created after the repair. You should never try to repair a directory database. 
Checking Database Integrity 
You can use ESEUTIL/g to check database integrity. This is a read-only utility that does not make changes to the database. It checks the database tables, rebuilds all indexes on a temporary database (Tempedb.edb), and compares the indexes. There are several switches to control the output and number of logs this command creates. 
Forcing Soft Recovery
This unique property allows an administrator to deal with a potential disaster. For example, a server has three databases, and experiences a hard drive failure. One of the databases was located on the lost hard drive. The server will first attempt a soft recovery. Once it encounters the lost database, it will report that the databases are no longer consistent and will cease the soft recovery. To get around this problem, the administrator can run ESEUTIL/R/I. R stands for soft recovery and causes the server to resume the soft recovery. I stands for ignore hanging attach records, and causes the server to ignore the missing database. After log redo completes, the first two databases will be consistent. The missing database will have to be restored from backup.