Exchange server 2010 event id 106 ve sürekli database boyut artışı hakkında

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.

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 ).

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.

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, see the following topics in the Exchange Server Database Utility Guide:

• 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
  


• Database Recovery Strategies
  


• Reference for Common Eseutil Errors