Exchange Mailbox Database De fragmentation

Exchange Server Database Defragmentation Process

Database white Space:
The database size on the physical disk is not just the number of users multiplied by the user
quota. When the majority of users are not near their mailbox quota, the databases will consume
less space, and white space is not a capacity concern. The database itself will always have free
pages, or white space, spread throughout. During online maintenance, items marked for removal
from the database are removed, which frees these pages. The percentage of white space is
constantly changing with the highest percentage immediately after online maintenance and the
lowest percentage immediately before online maintenance.
The size of white space in the database can be approximated by the amount of mail sent and
received by the users with mailboxes in the database. For example, if we have 100 2-GB
mailboxes (total of 200 GB) in a database where users send and receive an average of 10 MB of
mail per day, the white space is approximately 1 GB (100 mailboxes 10 MB per mailbox).
White space can grow beyond this approximation if online maintenance is not able to complete a
full pass. It is important that our operational activities include enough time for online maintenance
to run each night, so that a full pass can complete within one week or less.
Methods to recover white space:
The Eseutil utility can perform an offline de fragmentation, which releases unused hard drive
space from Exchange Server databases to the file system. Eseutil requires free hard disk space
equal to at least 110 percent of the database size (to create a temporary database that is used in
the de fragmentation).
If no local drive has sufficient space for an offline de fragmentation, we can use one of the three
following options, which are expanded on in the "More Information" section of this article:
Offline de fragmentation with redirected temporary database. Redirect the temporary
database to another logical drive, such as a mapped network drive or a temporarily
installed hard disk.
Moving information to another server and recreating empty databases. Move all of the
information that either one or both of the information store databases contain to another
server. Stop the service, delete the databases, and then restart the service to recreate
empty databases.

Offline Defragmentation on another computer. Move the database files to another

computer, and then perform the offline defragmentation on that computer.

Recommendations for Database Defragmentation:

1. If we have deleted a large amount of data out o the store and want to reclaim the hard
drive space for whatever reason. This includes situations when databases reach the 16 GB
limit on Standard versions of Exchange server.

2. When we add more no of new users due to a merger or acquisition or when we delete
many objects from the store it can be necessary to do an offline defrag.
2. If we had to run a hard repair of the database ( eseutil /p - and that's another thing that
we do NOT recommend unless this is a last possible thing to do). After running a repair,
you should always offline defrag the database to get a new database file that has not been
repaired.
3. If we are experiencing a specific issue and have found a reference that says offline defrag
will fix it.
4. If we are working with PSS and resolving the issue requires an offline defrag.
5. As a general rule, only defrag to reclaim space if we're going to reclaim more than 30% of
the space. we can look for Event 1221 after nightly online defrag to get a conservative
estimate of how much free space is in the database.
What really happens when we do an offline defrag:
1. We need downtime to take your databases offline in order to run ESEUTIL on them.
2. Defrag actually works by reading the original database, and copying used database pages
into the brand new database file. When that is all done, we actually delete the original
database file and rename the new one and copy it into original database file's place.

3. Not only are the used pages read, but they are renumbered /recheck summed too. All
secondary indexes in the database are discarded as well.

How to find the white space of exchange database:

1.

Event ID 1221:
Event: 1221
Source: MSExchangeIS Public
Type: Information
Category: General
Description: The database "<storage_group>\<mailbox_store> (<server_name>)"
has <nnn> megabytes of free space after online de fragmentation has terminated.
2. ESEUTIL Filedump Mode:
We can do a space dump with ESEUTIL /MS to determine the space.

2.

The Eseutil utility can perform an offline defragmentation, which releases unused hard drive space
from Exchange Server databases to the file system.
References:
how to run defrag:
http://technet.microsoft.com/en-us/library/aa998863%28v=exchg.80%29.aspx
http://technet.microsoft.com/en-us/library/aa996139%28v=exchg.65%29.aspx
Database repair:
http://support.microsoft.com/kb/259851
http://support.microsoft.com/kb/192185
http://support.microsoft.com/kb/328804
http://support.microsoft.com/?id=255035

How to Run Eseutil /D (Defragmentation)

18 out of 23 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-12-20
This topic explains how you can use the Exchange Server Database Utilities (Eseutil.exe)
defragmentation command to defragment and compact an Exchange database offline. For more
information about using the Eseutil /D command, see Eseutil /D Defragmentation Mode.
Before You Begin
Before you perform the following procedure on an Exchange server that has a Mailbox server role, a
Hub Transport server role, or an Edge Transport server role installed, note the following:
Make sure you log on by using an account that is delegated membership in the local
Administrators group on that computer.
Make sure you have free disk space equal to 110 percent of the end size of the database that you
want to process.
Note:
You only need as much extra logical drive disk space as the final size of the files after
defragmentation. To get an approximate estimate of the database (mailbox or public folder
database) file size after defragmentation, look at application event ID 1221. This will tell you
how much free space is in the database file. From the current database size, subtract the amount
of free space specified in event ID 1221 to determine the approximate end size of the database
after defragmentation. Although it is impossible to precisely predict how much disk space will
be reclaimed, you should leave a recommended 110 percent of free disk drive space. Similar to
how the mailbox or public folder database generates event 1221 to report logical free space
after an online defragmentation, the Microsoft Exchange Server 2007 Edge Transport or Hub
Transport server Queue database files also generate an event ID 7007 that reports logical free
space after an online defragmentation. In addition, Queue databases on the Exchange 2007
Edge Transport or Hub Transport servers generate event ID 7006 to report logical free space
before the online defragmentation. The source for these events is MSExchangeTransport.
Dismount a mailbox or public folder database before defragmenting. During an offline
defragmentation, the dismounted mailbox or public folder database will be inaccessible to
clients. Before performing an Eseutil defragmentation on a transport Queue database (Exchange
2007 Edge Transport or Hub Transport server database), stop the Microsoft Exchange Transport
Service on the server. In addition, because the Queue database is offline during
defragmentation, messages from the Queue database will not be delivered through the Hub
Transport or Edge Transport server.
Procedure
To defragment an Exchange database on a mailbox server
1. In the Exchange Management Console, right-click the database that you want to defragment,
and then click Dismount Database.

2. At the command prompt, point to the <Exchange install folder>\bin location.

Note:
<Exchange install folder> is the folder where you installed Exchange. The default location is
\Program Files\Microsoft\Exchange Server.
3. Type the Eseutil /D command, a database switch, and any options that you want to use. For
example, the following command (all in one command) runs the standard defragmentation tool
on a mailbox database:
C:\program files\microsoft\exchange server\bin Eseutil /d c:\program
files\exchange server\mailbox\<storage_group_name>\<database_name>.edb

Note:
The default storage group name is First Storage Group, and the default database name is
Mailbox Database, so the default path is C:\Program Files\Microsoft\Exchange
Server\Mailbox\First Storage Group\Mailbox Database.edb.
Use the following database switch to run Eseutil defragmentation on a specific database:
Eseutil /d <database_name> [options]

To defragment an Exchange database on a mailbox server using additional options

To defragment an Exchange database while keeping the temporary file intact, from the
command prompt, run the following command:
eseutil /d <database_path_and_file_name> /p

Note:
This command can be valuable because it leaves the original database in place and does not
write over it. This option increases the amount of available disk space required for
defragmentation. This is because you will need space for two additional copies of the Exchange
database.
To defragment the Exchange database but have the temporary file on another logical drive, from
the command prompt, run the following command:
eseutil /d <database_path_and_file_name> /t
<temp_database_path_and_file_name>

Note:
If the logical drive is accessible over a network connection, this can affect the amount of time
that it will take defragment the database.
To defragment an Exchange database on a Hub Transport or Edge Transport server

1. To dismount the Queue database, from the Services snap-in, stop the Microsoft Exchange
Transport Service.
2. At the command prompt, point to the <Exchange install folder>\bin location.
Note:
<Exchange install folder> is the folder where you installed Exchange. The default location is
\Program Files\Microsoft\Exchange Server.
3. Type the Eseutil /D command, a database switch, and any options that you want to use. For
example, the following command (all in one command) runs the standard defragmentation tool
on a transport Queue database:
Eseutil /d c:\program files\exchange
server\TransportRoles\data\queue\mail.que

Note:
The default name of the Queue database is mail.que.

Determining the True Amount of Space in an

Exchange Database
6 out of 9 rated this helpful - Rate this topic

Topic Last Modified: 2006-03-08

By Jeremy Kelly
This article explains why the size of the Microsoft Exchange database may not equal the total size of
the space used by the mailboxes, and what the size listed in Event 1221 represents.

Event 1221
Space Management in the .stm File
Database Space Tree Dump (Eseutil /ms)
Why Do Exchange System Manager and Outlook Show Different Sizes for the Same Mailbox?
For More Information

Event 1221
When you receive Event 1221, you see the following:
Event: 1221
Source: MSExchangeIS Public

Type: Information
Category: General
Description: The database "<storage_group>\<mailbox_store>
(<server_name>)" has <nnn> megabytes of free space after online
defragmentation has terminated.
Note:
Even though the event shows "terminated," this is an expected behavior.
The number of megabytes (MB) of free space presented is derived from the number of free pages that
are available at the database root, messages tables, folders tables, and attachments tables. Statistically
these tables represent nearly 90 percent of the space used in the database.
To understand the reason for this, a review of database space management is needed. Consider the
following:
The fundamental space allocation in Exchange is a 4 kilobyte (KB) page.
A series of 16 consecutive pages is the amount of space that is allocated to a table when space is
requested. Exchange does not allocate one page at a time.
A page cannot store data from two different tables or belong to two different trees.
There are two levels of space management that occur in the database. One is at the global database
level, which is the space available to all tables in the database store in ranges of 16 consecutive pages,
and the other is at the b-tree level. If you are unfamiliar with the concepts of B+trees, it may be easier
to think of them as a table. Tables maintain the state of pages they own and do not free up pages to the
overall database until a 16 consecutive block of pages is freed. The reason for this is efficiency. By
reusing pages that are physically adjacent to existing pages, you minimize the effort necessary to
perform read and write operations. So by holding onto pages, you ensure that a larger majority of pages
for a specific table are physically adjacent.
In a database, you can have thousands of tables, at least one for each folder in every mailbox. As
previously mentioned, statistically the messages tables, folders tables, and attachments tables represent
90 percent of the space used in the database. These tables have the greatest percentage of free space,
commonly referred to as white space, in the database.
To arrive at a calculation for the amount of available space an individual table possesses, you must
interrogate the space usage information of the table. If you were to do this for thousands of tables, it
would take a large amount of time to perform this calculation. As a result, Microsoft considers only the
available space of the message, folder, attachment, and database root when logging Event 1221.
The database contains additional information that is not part of the mailbox allocation. For example,
there are search folders, indexes, and system tables that are required for Exchange to operate. In
addition, a page cannot belong to multiple tables. If a page has free space, it can only store new records
for that table, and it will only contain records that meet the criteria to be stored on that page. If you
stored every record beginning with the letter A on one page and every record beginning with B on a
second page, there is no reason that a record beginning with A should appear on the page containing all
the B values. Therefore, there can be space available on an individual page that is not taken into
consideration when calculating Event 1221, because Event 1221 only adds the empty or free pages in
the tables mentioned previously.

Online defragmentation compresses records to fewer pages in a particular table. For example, if a table
owns 100 half-full pages, online defragmentation will attempt to free approximately half of the pages.
When 16 contiguous pages are freed, the space is released to the database to be used by other tables. It
is only the pages that are freed in the previously mentioned tables that eventually get reported.
Space Management in the .stm File
Space management for the .stm file is different from the logic in the .edb file. In the .stm file, data is
still arranged in 4 KB pages, however, the page state information is not maintained in the .stm file. This
is done in the .edb file. Pages in the .stm file have four primary states:

Free Currently does not contain data and is available to accept new incoming data.
Reserved Has new data from an inbound message, but has not been committed.
Committed Contains data currently referenced by records in the .edb file.
Deleted A page that is being freed, but is not ready to accept new data.

Inside the .edb file, two tables exist to manage the contents of the .stm file, SLVAvail and
SLVSpaceMap. In the .stm file, which is referred to as the SLV file in Extensible Storage Engine (ESE)
source, space is managed in 512 page chunks. In the SLVAvail table, entries are maintained for each
512 page chunk. Two bits are used to describe the state of each page in the 512 page chunk. When a
new space request is received, which is a new incoming Simple Mail Transfer Protocol (SMTP)
message, this table is queried to locate space in the .stm file to store the message. A series of pages is
returned to SMTP in the form of a file handle.
The SLVSpaceMap table allows for reverse lookup of pages in the database to map to a particular table,
row, and column that references a particular page in the .stm file. It also records the checksum of a page
in the .stm file.
Database Space Tree Dump (Eseutil /ms)
If you want a more in-depth look at the space used in the database, a space dump using Exchange
Server Database Utilities (Eseutil) is necessary. Note that the following example is truncated for
brevity:
C:\Program Files\Exchsrvr\MDBDATA>..\bin\eseutil /ms priv1.edb
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: priv1.edb
****************************** SLV SPACE DUMP
*************************
Chunk

Free Res Del Com

|------------ Used ------------|

=====================================================================
==

512

110

1024

0 512

0 402

*************************

********************************

1536

512

2048

512

2560

512

3072

512

3584

512

4096

512

4608

118

0 394

************************

5120

0 512

********************************

5632

0 512

********************************

6144

0 512

********************************

6656

0 512

********************************

7168

0 512

********************************

7680

0 512

********************************

8192

238

0 274

*****************

=====================================================================
==
TOTALS:
Free:

3538

Reserved:

512

Deleted:

Committed:

4142

Unknown:

0
------------8192

*********************************************************************
**
******************************** SPACE DUMP
***************************
Name
Available

Type

ObjidFDP

PgnoFDP

PriExt

Owned

=====================================================================
==

priv1.edb
116

256-m

8960

<SLV Avail Map> SLV

29

33

32-m

32

<SLV Owner Map> SLV

3

65

32-m

80

75

301

8-s

77

302

1-s

MsgFolderIndexPtagDel Idx
0

80

305

1-s

MsgFolderIndexURLComp Idx
0

79

304

1-s

RuleMsgFolderIndex
0

78

303

1-s

61

236

2-m

7778

222

237

1-m

7691

63

257

8-s

MsgFolderIndex7 Idx
0

65

258

1-s

MsgFolderIndexPtagDel Idx
0

68

261

1-s

MsgFolderIndexURLComp Idx
0

67

260

1-s

RuleMsgFolderIndex
0

66

259

1-s

1-122
3
MsgFolderIndex7
0

Db

Tbl
Idx

Idx

1-23
16

Tbl

<Long Values>
8

LV

1-24
3

Tbl

Idx

1-33
1

Tbl

336

8821

8-m

14

<Long Values>
2

LV

342

8826

1-m

354

8827

1-s

338

8822

1-s

?T668f-T6654+Q3f88
0
MsgFolderIndex7
0

Idx
Idx

MsgFolderIndexPtagDel Idx
0

341

8825

1-s

MsgFolderIndexURLComp Idx
0

340

8824

1-s

RuleMsgFolderIndex
0

339

8823

1-s

97

9-m

100

105

243

1-s

*T668f+Q6749+S3001+Q6 Idx
0

60

232

1-s

?T668f+Q6749+S3001+Q6 Idx
0

59

109

1-m

Folders Fid to Pfid I Idx

2

17

108

1-m

FoldersIndex10
0

Idx

13

102

1-s

FoldersIndex13
0

Idx

14

103

1-s

FoldersIndex5
1

Idx

98

1-m

FoldersIndex6
0

Idx

10

99

1-s

FoldersIndex7
0

Idx

11

100

1-m

FoldersIndex8
0

Idx

12

101

1-s

Hashed URL Name Index Idx

0

15

104

1-m

ScopeFIDs DeleteTime
0

16

105

1-s

Folders
10

Tbl

<Long Values>
0

LV

Idx

Idx

Mailbox
2

Tbl

21

140

2-m

10

MailboxIndex2
0

Idx

22

141

1-s

MailboxIndex3
0

Idx

23

160

1-s

Msg
63

Tbl

<Long Values>
0

LV

19

112

2-m

194

106

359

1-m

14

---------------------------------------------------------------------253
The first section of output is the space dump of the .stm file. The output is directly from the contents of
the SLVAvail table in the .edb file. Each 2 MB-chunk, which is 512 pages, is listed to the left. The
columns represent the number of pages in each state in the .stm file. The last piece of information is a
graphical representation of the amount of space used in the individual 2 MB chunk.
****************************** SLV SPACE DUMP
******************************
Chunk

Free Res Del Com

|------------ Used ------------|

=====================================================================
==
512
1024

110

0 512

0 402

*************************

********************************

1536

512

2048

512

2560

512

3072

512

3584

512

4096

512

4608

118

0 394

************************

5120

0 512

********************************

5632

0 512

********************************

6144

0 512

********************************

6656

0 512

********************************

7168

0 512

********************************

7680

0 512

********************************

8192

238

0 274

*****************

=====================================================================
==

TOTALS:
Free:

3538

Reserved:

512

Deleted:

Committed:

4142

Unknown:

0
------------8192

Consider the following section of output. There are two columns, owned and available. The owned
value is the number of pages in the database that contains some data. The available value represents the
number of free pages available at the database root that can be distributed to tables as they need space
to grow.
******************************** SPACE DUMP
***************************
Name
Available

Type

ObjidFDP

PgnoFDP

PriExt

Owned

=====================================================================
==
priv1.edb
116

Db

256-m

8960

Consider the attachments table in the following section of output. There are two rows, one called 1-23,
which is the primary B+tree containing actual records, and then one called <Long Values>, which
contains binary blobs or fragments of records that are larger than 1 KB and cannot be stored in the
primary B+tree. The value under the owned column for 1-23 is 7778. This represents the total number
of pages owned by this table and all associated B+trees. This encompasses the primary B+tree, long
values trees, and any other secondary indexes that could be in use by this table. The next value is the
available pages, in this case 16, that can be reused by this individual table, but not by indexes or the
Long Value tree. Of the 7,778 pages in use by this table, the long value tree is occupying 7,691 and
there are 8 pages available:
******************************** SPACE DUMP
**************************
Name
Available

Type

ObjidFDP

PgnoFDP

PriExt

Owned

=====================================================================
==
1-23
16

Tbl

<Long Values>

LV

61

236

2-m

222

237

1-m

7778

7691

Consider a standard folder in use by someone in the database. The folder is 1-33. Note that internally,
Microsoft represents tables as numbers referred to as IDs. This would typically represent a user's Inbox
folder or other folder that the user created. In this case, there is a primary entry, 1-33, that is the table
itself. Listed under this row are associated Long Value and indexes to this table. There are also five
secondary indexes associated with this table.
Note:
Indexes come in two types, those created by schema and those created dynamically. In the following
output, for example, MsgFolderIndex7 would be considered a schema index. When the Microsoft
Exchange Information Store service creates this table, it also creates an index with this name.
Dynamically created indexes have an unusual, but logical naming convention. In the following
example ?T668f-T6654+Q3f88 is a dynamically created index with a key value being the aggregate of
the columns T668f, T6654, and Q3f88.
Overall, this table occupies 14 pages with 1 page available to the primary table. The Long Value owns
5 of the 14 pages owned total by this table, and has 2 free pages, while the table entry only has one. The
Owned value represents all pages in use by the table, indexes, and LV trees. The Available only
represents the number of pages available to that individual index/LV/Table and is not cumulative:
******************************** SPACE DUMP
***************************
Name
Available

Type

ObjidFDP

PgnoFDP

PriExt

Owned

=====================================================================
==
1-33
14

Tbl

336

8821

8-m

LV

342

8826

1-m

354

8827

1-s

338

8822

1-s

MsgFolderIndexPtagDel Idx
1
0

341

8825

1-s

MsgFolderIndexURLComp Idx
1
0

340

8824

1-s

RuleMsgFolderIndex
1
0

339

8823

1-s

<Long Values>
5
2

?T668f-T6654+Q3f88
1
0
MsgFolderIndex7
1
0

Idx

Idx

Idx

At the end of the dump is a line similar to the following. It contains a summation of the total number of
pages that are available throughout all the tables. By multiplying this value by 4,096, you determine the
true amount of white space in the database:

---------------------------------------------------------------------253
When studying a space dump to understand where space is being used in the database, first look to the
attachments table (1-23), messages table, and folders table, and determine how much space these three
tables occupy. If these tables combined do not represent the majority of the size of the database, the
space is being consumed by some other table or indexes. Examine the output for suspicious entries
occupying a large amount of space, or many small tables combined that consume a large amount of
space.
In this example, mailbox size matches the size of the database. The reason is that the tables that
actually store the data could occupy a larger amount of space depending upon the density of the pages
at the time, and if pages have been freed up to the database root. In most cases, this has proven to be
the situation.
Why Do Exchange System Manager and Outlook Show Different Sizes for the Same Mailbox?
When a calculation is performed for a size of a mailbox, consider the following:
Microsoft Outlook takes into account only what a user can see from the mailbox, so only
items that a user can see from the Outlook client in the mailbox folders are calculated.
Within a mailbox, many hidden items exist. Some of these items include third-party hidden
folders, rules, and items used to support the functionality included with an Exchange mailbox.
These hidden items are sometimes referred to as NON_IPM_DATA. Exchange System Manager
considers all related mailbox data, including NON_IPM_DATA when calculating the size of a
mailbox.
This implies that the size of the mailbox is usually bigger when viewing it from Exchange System
Manager, rather than viewing it from Outlook client.
There are also several bugs related to size calculations that may be a factor in understanding these
discrepancies. If you incur this problem and subsequently apply a fix to correct the problem, the size
counts may appear to be different until the Information Store Integrity Checker (Isinteg) is run to
correct the item count issues. In general, if you are attempting to understand an item count or size issue,
ensure you are running the latest version of the Microsoft Exchange Information Store service, and you
have run Isinteg after applying the fix. For information about fixes that can affect mailbox size
reporting, see the following Microsoft Knowledge Base articles:

Ramifications of running the eseutil /p or

edbutil /d /r command in Exchange
Article ID: 259851 - View products that this article applies to.
Retired KB Content Disclaimer

This article was previously published under Q259851

Expand all | Collapse all

SUMMARY
A hard repair occurs when you run an eseutil /p or edbutil /d /r command against an Exchange
Server database file, such as the Priv.edb, Pub.edb, or Dir.edb database. The repair goes through
the database and checks and repairs critical structures inside the database (such as system tables,
attachment tables, and so on) and checks for damaged pages in the databases.
If the repair encounters a page that is damaged (for example, an invalid checksum caused by a
modification to the page that was not preformed by Jet) it deletes the page (-1018). When this
happens, critical data may be lost after the repair finishes. This data may be part of an e-mail
message, a calendar appointment, a note, an attachment, or in the worst-case scenario, part of a
system table.
If that system table is the attachment table, every user on the server may lose the attachments to
their messages. This is only one possible scenario, but if there are damaged pages in the database,
data will be lost following a hard repair.
Important It is always best to restore from a backup whenever possible.
If you restore from a backup, you ensure that you have a good, clean, stable, database that will
start and run on your server. In almost every circumstance, it is faster and more reliable to restore
from a backup than to perform a hard repair on the database. This is because the repair runs at
approximately 4 to 6 gigabytes (GB) per hour, and you must run the Isinteg process after the
repair, which runs at approximately 3 to 6 GB per hour. (These rates are average; performance
may vary depending on how many passes the repair has to make on your database and the speed
of the hardware.)
For example, if you use the fastest possible hardware setup, a 50-GB database requires
approximately 8 hours for repair and approximately 8 hours for the Isinteg process, for a total of
16 hours. If you use a typical Wide SCSI-connected digital linear tape (DLT) 35/70, which
averages around 3 megabytes (MB) per second for restoration, the same database needs
approximately 5 hours for restoration. That is a time savings of 11 hours. Extremely high speed
"snapshot" type backup systems, such as the system from EMC Corporation, can restore a
database of this size in a matter of minutes.
If you have no backup, and no other option but to run a hard repair on your database, follow
these steps:
1. Run a hard repair on the database by using Eseutil /p or Eseutil /d /r.
2. Defragment the database by using Eseutil /d. Offline defragmentation creates a new
physical database structure and moves the existing data to that structure.
3. Check the consistency of the database by using Isinteg -fix. You may need to run Isinteg
several times until the summary report returns no errors.

For more information, click the following article number to view the article in the Microsoft
Knowledge Base:
192185 How to defragment with the Eseutil utility (Eseutil.exe)
182081 Description of the Isinteg utility
The Isinteg utility fixes the logical problems that may arise when you run a hard repair:
For the Exchange Server 4.0 and 5.0 private information store, run the following
command:
isinteg -fix -pri
For the Exchange Server 4.0 and 5.0 public information store, run the following
command:
isinteg -fix -pub
For the Exchange Server 5.5 private information store, run the following command:
isinteg -pri -fix -test alltests
For the Exchange Server 5.5 public information store, run the following command:
isinteg -pub -fix -test alltests
Note You cannot run the Isinteg -fix command against the Dir.edb database. Additionally, we
recommend that you do not run a hard repaired directory in a production environment.
For more information about Exchange disaster recovery, click the following article number to
view the article in the Microsoft Knowledge Base:
162353 Restoring an Exchange Directory
After you run the eseutil /p or edbutil /d /r command on the Priv.edb or Pub.edb databases, the
databases may exhibit the following symptoms:

The information store either will not stop or stops responding.

The information store stops accepting mail from the message transfer agent (MTA).
E-mail remains in the Outboxes of the users.
The Store.exe program runs with very high CPU use with no load on the server.
The Store.exe program generates an access violation if there is a heavy load.
Users cannot open e-mail attachments or e-mail messages.

After you run a hard repair on a database that has extensive damage, it is not fit for production
use until you have also performed the offline defrag followed by isinteg. Only run a hard repair
on your database as a last resort; if possible, always restore from a backup.
If Isinteg is run multiple times and does not correct the database corruption, you must use the
Exmerge utility to extract data from one database and place it in another database:
259688 How to use the Exmerge utility to extract data from a damaged private information store

MORE INFORMATION
To determine if a hard repair has been run against your database, dump the header by using the
following command line (the repair count will be zero if the databases have not been repaired):
eseutil /mh x:\exchsrvr\mdbdata\priv.edb |more

eseutil /mh x:\exchsrvr\mdbdata\pub.edb |more

The following is a sample of a Priv.edb header:
Microsoft(R) Windows NT(TM) Server Database Utilities
Version 5.5
Copyright (C) Microsoft Corporation 1991-1999. All Rights Reserved.
Initiating FILE DUMP mode...
Database: d:\exchsrvr\mdbdata\priv.edb
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,2
Engine ulVersion: 0x620,2
DB Signature: Create time:4/5/2000 17:48:52 Rand:769046 Computer:
cbDbPage: 4096
dbtime: 556457
State: Consistent
Shadowed: Yes
Last Objid: 184
Scrub Dbtime: 0
Scrub Date: 00/00/1900 00:00:00
Repair Count: 1
Repair Date: 2/20/2000 10:48:50

Eseutil /D Defragmentation Mode

5 out of 6 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2009-03-16
You can use the Exchange Server Database Utilities (Eseutil.exe) /D switch to defragment and compact
a database offline. The defragmentation option makes used storage contiguous, eliminates unused
storage, and compacts the database, which reduces the database file size.
For instructions about how to use the Eseutil /D syntax, see How to Run Eseutil /D (Defragmentation).
During normal 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 placed in service, but eventually the database
size stabilizes.
Under normal conditions, performing an offline defragmentation does not permanently recover
significant disk space. The file will tend to grow again to its previous size before defragmentation.

How Eseutil Defragmentation Works

As part of the defragmentation process, Eseutil creates a new database that contains all the information
in the original database. When defragmentation is complete, the original database is deleted or saved to
a user-specified location, and the new version is renamed as the original. If the tool encounters a bad
record, it stops and displays an error message.
When an offline defragmentation is performed, Exchange makes a temporary copy of the database file.
Tables from the database file are preserved and copied into the temporary database, but empty pages
are discarded and indexes are rebuilt. Because this action causes physical page numbers in the database
to be changed, pages are not copied unaltered. The page links between pages are all updated, and all
pages left in the database undergo integrity checks.
Length of Time to Defragment a Database
The length of time required 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-gigabyte (GB)
database containing 10 GB of data takes about the same time as defragmenting an 11-GB database
containing 10 GB of data.
By default, after defragmentation is complete, the temporary database automatically becomes the new
production database, and the original production database file 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 placed 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 using a
network drive for the temporary database, defragmentation takes longer, and any transient or permanent
network error will end the defragmentation process. Because defragmentation cannot be resumed, you
must 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 precisely predict how much disk space will be reclaimed,
you should leave a recommended 110 percent of free disk drive space.
How to Determine the Amount of Free Space in a Database
The amount of free space that is available in an Exchange database file is displayed in an event that is
logged in the event log after an online defragmentation of the database is performed. The online
defragmentation is performed automatically during normal database maintenance. In addition, the event
is logged in the event log even if the associated logging level is set to None.
For mailbox or public folder databases, an event similar to the following event is logged in the event
log:
Event Type: Information
Event Source: MSExchangeIS Mailbox Store
Event Category: General

Event ID: 1221

Date: 8/16/2006
Time: 9:15:00 AM
User: N/A
Computer: Computer Name
Description: The database "storage_group\mailbox_database" has nnn megabytes of free space after
online defragmentation has terminated.
Note:
In Exchange Server 2007, the event ID 1221 message description contains the following text: The
database "storage_group\mailbox_database" has nnn megabytes of free space after online
defragmentation has terminated. Storage_group is the name of the storage group, mailbox_database
is the name of the mailbox database, and nnn is the amount of free space that is available in
megabytes. The Computer Name is the name of the Exchange Server computer.
For queue databases (transport databases that reside on Exchange Edge Transport or Hub Transport
server roles), an event similar to the following is logged in the event log:
Event Type: Information
Event Source:MSExchangeTransport
Event Category: Components
Event ID: 7007
Date: 8/16/2006
Time: 1:00:02 AM
User: N/A
Computer: Computer Name
Description: Online defragmentation has completed for database mail.que. The database has nnn free
bytes.
Note:
In the preceding description, nnn is the amount of free space available in bytes. The Computer Name is
the name of the Exchange Server computer.
Another method to determine the amount of free space is by running a space dump with Eseutil /ms
against an offline database file. (For example, run the following command: eseutil /ms Mailbox
Database.edb.) The space dump outputs a table. From the table, take the number in the
Availablecolumn and multiply it by the page size to determine the free space for the database file. For
more information about the Eseutil file dump mode, see Eseutil /M File Dump Mode.
When to Run Eseutil /D
There are several situations where it is appropriate to run Eseutil /D to defragment an Exchange
database. The following list describes some of those situations:

 There is a significant amount of free space in the database that can be reclaimed and that will
not be reused.
There are ESE -1018 errors affecting the indexes of a database file. In such instances, offline
defragmentation rebuilds the indexes. Running an offline defragmentation effectively eliminates
this corruption.
A database file has been repaired using Eseutil /P. After running repair, Eseutil offline
defragmentation should be performed on the database file.
A mail storm occurs on a queue database file residing on an Exchange 2007 Hub Transport or
Edge Transport server. A mail storm is a large amount of mail that fills up the transport queue
faster than the transport service can process the e-mail messages. This behavior causes the
queue to fill with mail, and the Queue database expands when it needs to. When the mail from
the storm has been processed, and an online defragmentation has been run on the database,
some amount of free space remains in the database. To reclaim this free space and shrink the
database, run Eseutil /D to perform an offline database defragmentation.
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 list describes some of those situations:
Eseutil offline defragmentation 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. For day-to-day, month-to-month, or year-to-year maintenance, there
is no reason to run an offline defragmentation.
Eseutil defragmentation should not be run when the database is not in a consistent state.
Eseutil offline defragmentation should not be run when there is an available database to which
mailboxes could be moved. Doing so will cause less downtime for end users. Because offline
defragmentation is done offline, users will not have access to their mailboxes during
defragmentation. We recommend that to reduce the impact to the end user, you move the
mailboxes to a different database if available by performing a Move Mailbox operation. For
more information, see Moving Mailboxes.
Eseutil offline defragmentation should not be run when ESE -1018 errors affect the data portion
of a database file. In such cases, offline defragmentation will detect the error and not proceed.
For More Information
For more information about Eseutil, see the following topics:

Eseutil /P Repair Mode

Eseutil /C Restore Mode
Eseutil /R Recovery Mode
Eseutil /G Integrity Mode
Eseutil /M File Dump Mode
Eseutil /K Checksum Mode
Eseutil /Y Copy File Mode
Reference for Common Eseutil Errors

To ensure that you are reading the most up-to-date information and to find additional Exchange Server
2007 documentation, visit the Exchange Server TechCenter.

Eseutil /P Repair Mode

3 out of 3 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-08-28
The Exchange Server Database Utilities (Eseutil.exe) repair mode corrects problems in the transport
server queue database, mailbox database, and public folder database at the page and Extensible Storage
Engine (ESE) table levels. However, Eseutil does not correct problems at the application level.
Therefore, after you repair a mailbox or public folder database using Eseutil, we recommend that you
run the Information Store Integrity Checker (Isinteg.exe) to repair the database at the application level.
Note:
Isinteg is not applicable to Exchange Hub or Edge Transport server queue databases. For more
information about transport server queue databases, see Working with the Queue Database on
Transport Servers.
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. You can use Isinteg to perform this
application-level analysis and repair on mailbox and public folder databases. The following example
illustrates how the repair mode in Eseutil 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 does not correlate the message with the reference to it in each Inbox folder because Eseutil
does not have the information about the cross-table schema of the application. Isinteg is needed to
compare the repaired message table with each Inbox to remove a lost message from the Inbox folder.
Eseutil looks at each Exchange database page and table and ensures consistency and integrity within
each table. Isinteg repairs a mailbox or public folder 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. Run Eseutil in /P mode to perform a database page-level and table-level repair.
2. Run Eseutil in /D mode to fully rebuild indexes and defragment the database.
3. Run Isinteg only on the mailbox or public folder database to repair the database at the
application level.
Note:

Always back up your mailbox, public folder, or transport server queue database before running
a repair against it, because the repair results in some data loss. For example, in some cases,
when the system metadata might get lost, the database is not able to be mounted.
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 (used on mailbox or public folder databases) generate detailed repair log files
that list the errors found and corrected. For more information about causes and consequences of
specific errors, see Reference for Common Eseutil Errors.
Eseutil /P Best Practices
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 transaction logs forward, consider a hybrid strategy. 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.
We recommend 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 you can restore from backups without any data loss.
You can run Eseutil repair mode on a mailbox or public folder database to correct an error
-1018. Eseutil discards the -1018 page and performs the repair. A Microsoft WebCast for
Microsoft Exchange Server 2003 discusses how to correct an error -1018. For more
information, see Microsoft Knowledge Base article 812531, Support WebCast: Microsoft
Exchange: Understanding and Resolving Error -1018.

Eseutil /C Restore Mode

6 out of 6 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-09-05
The Exchange Server Database Utilities (Eseutil.exe) restore mode can only be run on mailbox and
public folder databases restored from legacy streaming backups. This topic does not apply to transport

queue databases on the Edge and Hub Transport server roles because the queue databases are not
backed up. The Eseutil restore mode also allows you to view the Restore.env file. The Restore.env file
is created when restoring an online backup of the database, and it controls the hard recovery process.
Hard recovery is the process that changes a restored database back to its clean shutdown state by
playing transactions into the database from transaction log files. The hard recovery process controls
transaction log file replay into a database that has been restored using the legacy streaming backup
application programming interface (API). This process is different from a soft recovery that takes place
after restoring a database using the Volume Shadow Copy Service (VSS) backup API as well as after
recovering from a failure.
Backup applications that implement the Exchange legacy streaming 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 NT Backup, this 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 prompt with Eseutil before a restored database can be mounted. To initiate hard
recovery, you can select the Last Backup Set check box in the backup API when you restore your last
database, or you can use the Eseutil /CC command. In this command, the first /C indicates restore
mode and the second C is the mode modifier to start the hard recovery process. The hard recovery
process uses the Restore.env file that is generated during the restore process to determine how to
restore the database files and to determine what transaction log files must be replayed from the
temporary directory that the backup was restored to. After the databases are copied to their destination
location, and the transaction log files from the temporary directory are replayed into them, hard
recovery continues to replay any additional transaction log files that it finds in the transaction log file
path specified for the storage group of the restored database.
For instructions and syntax for running Eseutil /C, see How to Run Eseutil /C (Restore).
Controlling Transaction Log File Replay
Transaction log file replay behavior using Eseutil /CC depends on whether the database has been
victimized. If you are restoring to an alternative server, or you have deleted and re-created the original
database, only transaction logs in the temporary folder are replayed. Transaction logs in the normal
database folder are not replayed. This distinction avoids transaction log replay conflicts in cases where
Exchange Server knows that the database to which it is restoring is not the same as that from which it
was backed up. A database restored in this circumstance is called a victimized database.
Important:
After hard recovery succeeds, all files in the temporary folder (where Restore.env was created) are
deleted. Never place your only copy of a log file in the Restore.env temporary folder.
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, 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 Restore.env.
If circular logging is currently enabled or was enabled at the time the backup was made, only
log files listed in Restore.env will be replayed.
If no log files exist in the running storage group log folder, recovery will complete successfully
using only the log files 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, 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, transaction logs will be replayed as follows:
Any other databases in the recovery storage group 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 recovery storage group 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.

Eseutil /R Recovery Mode

4 out of 10 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2011-06-16
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 follows a database restoration from an
online backup
Soft recovery: A transaction log replay process that occurs after any of the following activities:
a database is remounted after an unexpected stop

 transaction logs are replayed into an offline file copy backup of a database
logs are replayed into a Volume Shadow Copy Service (VSS) backup set
For more information about syntax and about running Eseutil /R recovery mode, see How to Run
Eseutil /R (Recovery).
Hard Recovery
Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all
other recovery scenarios, soft recovery occurs. You can use Exchange Server Database Utilities
(Eseutil.exe) to perform a hard recovery by using by using the Restore mode (/C).
Soft Recovery
In the most common 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 at the oldest log file available in the
transaction log folder for the storage group.
Exchange writes completed transactions to the database files. These are transactions that are found in
the log file and that have not already been written. Exchange then reverses any incomplete transactions.
Exchange never begins writing a transaction into the database files until all the operations composing it
are secured to the log files. You do not have to physically undo or stop a transaction in the database if
all uncommitted transaction logs that exist when the unexpected stop occurs also exist 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 either by the failure or by the administrator after the failure.
Specific Recovery Scenarios
The following sections describe various recovery scenarios.
Transaction log files are not in the current folder
Generally, you should always run Eseutil /R from the folder that contains the transaction log files to be
replayed. This is because the default soft recovery process looks in the transaction log files to find the
path to the databases. If you run Eseutil /R from a folder in which no log files exist, a new transaction
log file is generated, and this new log file will not contain the location of the databases. If you want to
run a soft recovery from outside the transaction logs folder, add the following switch to the command:
/Lpath_to_logfiles

For example, add this switch:

Eseutil /R E00 /Ld:\exchsrvr\logfiles

Controlling the checkpoint file

When you manually run a soft recovery, you usually want to either delete or hide the checkpoint file.
This is because, typically, you want to replay all available transaction logs instead of starting from the
middle of an available sequence.
If you are running a soft recovery from a folder that contains a valid checkpoint file, and you do not
want 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 you restore an offline backup to a storage group in
which databases are running.
If you are running recovery from a different folder, and you want to use the checkpoint file to control
recovery, you must point to the path for the checkpoint file.
If you want to control the use of the checkpoint file during a soft recovery, add the following switch to
the recovery command:
/Spath_to_or_away_from_current_checkpoint

For example, add this switch:

Eseutil /R E00 /Sd:\

Recovering a storage group with a missing mailbox or public folder database

If a storage group is unexpectedly stopped, and one of the inconsistent mailbox or public folder
databases is removed or unavailable, you cannot mount any of the databases in the storage group until
you restore the missing database or until you run manual recovery by using the /I switch.
Important:
Before you run a recovery that ignores the missing mailbox or public folder database, you should make
a backup copy of all transaction log files, including the current log file, (Enn.log). Enn.log is changed
through the process of recovering the other databases. After this, it may not be useable for recovering
the missing database if it is made available again.
Recovering a database out of place
Recovering a database that is out of place completely isolates the recovery process from the running
storage group. Use this method when you want to recover an offline backup in a recovery storage
group, and you intend to play any log files into the backup.
To prepare to do this procedure, you should move the database file and all transaction logs that you
intend to play into a single temporary folder. From this folder, you can run the following command:
Eseutil /R Enn /I /D

For example, run this command:

Eseutil /R E00 /I /D

The /I switch 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.
If the /D switch does not exist, the database paths that are recorded in the transaction log files are used
to locate the databases. If the /D switch is used without a path, the current directory is used as the path
for the database files. If the /D switch is immediately followed (with no intervening space) by a file
path, that path is used to locate the database files.
To avoid typing errors, we strongly recommend that you eliminate the need for using paths that have
Eseutil switches whenever possible . To do this, run Eseutil from a folder in which all data files already
exist.
After recovery finishes and the database files are in clean shutdown state, the files may be moved into
the appropriate storage group and attached to the log files, thereby mounting the databases.
Note:
To make sure that a database mounts, you may have to click to select the This database can be
overwritten by a restore check box on the database object properties in the Exchange Management
Console.
Recovering a database that has missing log files
In Exchange Server 2007, a new feature named Lost Log Resilience (LLR) protects Exchange
databases from losing the last few log files, and enables faster recovery. When an LLR-protected log
file is missing or corrupted, typical database mounting or recovery by using Eseutil fails and does not
provide the new /A recovery option. Event ID 523 is logged to the Event log and states the kind of
failure that occurred. On a database on which an LLR-protected log file is missing or corrupted, you
can run Eseutil recovery by using the /A option in recovery mode as follows:
ESEUTIL /R Enn /A
By default, in a non-clustered Exchange Server 2007 server, only the last file is protected by LLR.
Therefore, this option can be used only when the last transaction log file is missing. For more
information, see Lost Log Resilience and Transaction Log Activity in Exchange 2007.
Note:
You can see the command-line reference and syntax for Eseutil by typing eseutil /? at a command
prompt. However, the /A option is not listed in the Exchange 2007 RTM version of the command-line
reference.
When you recovered a database that had missing log files in previous versions of Exchange, you would
have to either restore databases from backups or repair the existing database file by using Eseutil /P.
With Exchange 2007, database recovery is enhanced so that you can recover a database that has log
files missing in the LLR range by running the recovery command and using the /A option.

Eseutil /G Integrity Mode

2 out of 2 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-08-18
Exchange Server Database Utilities (Eseutil.exe) integrity mode is a reliable way to verify whether an
Exchange Server database contains specific inconsistencies such as bad pages, inconsistent data,
flipped bits, missing data, or other issues that could appear in a database. 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 types of anomalies or inconsistencies to take proper steps to fix the
database. You should recover the database to a clean shutdown state before running an integrity check.
Many of the integrity checks involve reconstructing indexes and other data inside a temporary
database. Then, 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, there is greater likelihood of running out
of disk space during the check. You can add the T switch to the Eseutil /G command to redirect the
scratchpad or temporary database to a drive with more space.
Note:
The Eseutil integrity mode does not perform a database recovery. If a database is inconsistent or is in a
dirty shutdown state, we recommend 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 performing an integrity check using Eseutil, see How to Run Eseutil /G
(Integrity).

Eseutil /M File Dump Mode

4 out of 5 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-08-18
Although the Exchange Server Database Utilities (Eseutil.exe) file dump mode is often overlooked by
administrators, it is a valuable 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, you can run the following file dump command to dump the header of an Exchange
mailbox database to determine if your database has been repaired using the Eseutil /P command:
ESEUTIL /mh C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage
Group\Mailbox Database.edb |more

If a repair has occurred, the output of the file dump has information similar to the following:
Repair Count: 2
Repair Date: 08/10/2006 09:19:57
In file dump mode, you can:
View header information for 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.
View metadata for all tables or for a specific table in the database file.
For more information about syntax and about running Eseutil /M with different switches, see How to
Run Eseutil /M (File Dump).
The header for checkpoint, transaction log, and database files is the first physical page of each file.
Some files have a shadow header, which is 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.
Table 1 shows you switches that you can use to view headers of different types of database files.

Table 1 Switches and related headers of database files

You can use
the

To

View the header information of Exchange database files (.edb) for any ESE database
Eseutil /mh
including the Microsoft Exchange Server 2007 Hub Transport and Edge Transport server
switch
role Queue databases.
Eseutil /ml Validate the integrity and sequence of transaction log files for any Exchange 2007 ESE
switch
database.
Eseutil /mk
View the header information for Exchange database checkpoint files.
switch

Eseutil /K Checksum Mode

1 out of 2 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-08-18
The Exchange Server Database Utilities (Eseutil.exe) tool in Microsoft Exchange Server 2007 includes
a /K switch that you can use to verify the page-level integrity of Exchange databases. The /K switch
can be used to detect file header damage. File header damage may occur in databases, log files, or
checkpoint files. In addition, you can use the Eseutil /K command to verify the checksum integrity of
the transaction log stream when all the databases in the storage group are dismounted.
For more information about procedures and syntax for running Eseutil in checksum mode, see How to
Run Eseutil /K (Checksum).
With the inclusion of Extensible Storage Engine (ESE) file features, Eseutil can checksum log files and
checkpoint files. Checksum mode doesn't allow you to checksum individual pages in the database.
However, you can use the page dump mode to determine whether the checksum on any given page is
correct.

Eseutil /Y Copy File Mode

1 out of 1 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007
Topic Last Modified: 2006-09-02
The Exchange Server Database Utilities (Eseutil.exe) /Y copy file mode is optimized to copy very large
files efficiently. You can use the /Y switch to copy a database file or log file. However, the mode is not
suitable as a general purpose copy utility.
Depending on disk and network conditions, copy file mode may be able to copy a file up to 20 percent
faster than a normal copy because the copy file mode in Eseutil copies files in larger blocks of data.
Note:
Because copy file mode does not accept wildcard characters (such as *.* to copy all files or *.edb to
copy all database files), you must fully specify a file name and copy one file at a time.

Reference for Common Eseutil Errors

0 out of 1 rated this helpful - Rate this topic

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1,
Exchange Server 2007

Topic Last Modified: 2007-02-19

This topic covers common Extensible Storage Engine (ESE) database errors that you might encounter
when running Eseutil on Microsoft Exchange database files and transaction log files in a storage group.
Formerly known as JET, ESE is a method that defines a low-level API to the underlying database
structures in Exchange Server.
Error Codes
Table 1 describes some of the common database errors encountered when running Eseutil.

Table 1 Common database errors when running Eseutil

Error
numbe
r

JET error

Error description

Error
-327
JET_errBadPageLink
(0xfffff
eb9)

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 failure. A
failure can cause the error if the write ordering of
pages from the cache was not preserved, and
therefore only some pages from a transaction were
updated while other pages were left as older
versions.

Error
-501
JET_errLogFileCorrupt
(0xfffff
e0b)

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
JET_errLogWriteFail
(0xfffff
e02)

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 JET_errInvalidLogSequence
-515
(0xfffff
dfd)

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 fit with other logs in the sequence, or
if another problem is detected that 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
JET_errLogSequenceEnd
(0xfffff
df9)

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 1. Database behavior, after this limit is
reached, varies by Exchange version.

Error
-530
JET_errBadLogSignature
(0xfffff
dee)

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 failed and
the logs needed to recover it are no longer present.

Error
-531
JET_errBadDbSignature
(0xfffff
ded)

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, 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
JET_errBadCheckpointSignature
(0xfffff
dec)

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 scan every transaction log again
to determine whether it is needed for recovery. If
there are thousands of log files, this may take
several minutes or more.

Error
-533
JET_errCheckpointCorrupt
(0xfffff
deb)

This error indicates that a corrupt checkpoint file

has been deleted. In most versions of Exchange, a
corrupt checkpoint file will be deleted and recreated automatically. A corrupt checkpoint file
may be deleted because it cannot be used.

Error JET_errRequiredLogFilesMissing
-543
(0xfffff

This error indicates that log files are missing. An

Exchange database that has been shut down
correctly is in a clean shutdown state 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.

de1)

Note:
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.

This error indicates that instead of a 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
Error
recovery, as contrasted to soft recovery, which runs
-544
JET_errSoftRecoveryOnBackupDatabase after an ordinary database failure. Hard recovery is
(0xfffff
run by triggering transaction log replay within the
de0)
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.
This error may accompany error -519 and indicates
Error
that no more transaction log files can be generated
-548 JET_errLogSequenceEndDatabasesConsis in this sequence, but databases are all in a clean
(0xfffff tent
shutdown state. This means that it is safe to
ddc)
remove transaction log files and reset the log
sequence.
Error JET_errDatabaseInconsistent
-550
(0xfffff
dda)

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 a 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
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
JET_errConsistentTimeMismatch
(0xfffff
dd9)

Error
JET_errDatabaseCorrupted
-1206

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.
This is a generic error and does not necessarily
indicate a severe problem. The error will be
triggered 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 and Errors
Message Center.

Error
-1216
JET_errAttachedDatabaseMismatch
(0xfffff
b40)

Error
-93958
6631
(Unkno Unknown Error
wn
Error)

This error is closely related to error -551

(JET_errConsistentTimeMismatch). It typically
occurs after a simultaneous failure of all databases
in a storage group if one of the databases is no
longer available (for example, because its disk has
been destroyed).
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.
For more information about running Eseutil /CC,
see How to Run Eseutil /C (Restore). If the issue
persists, the database might need to be restored or
repaired.