exchange2003 数据库磁盘只剩下4G了

martionch

exchange2003 数据库磁盘只剩下4G了。其中priv1.stm就有70G了，priv1.edb也有7G了。
现在有什么办法可以减少这两个文件大小 ，或者新建数据库，怎么迁移用户呢？


进行数据库碎片整理是对priv1.edb进行整理还是对priv1.stm进行整理？
谢谢

钉子

https://support.microsoft.com/zh ... -exchange-databases
https://technet.microsoft.com/en-us/library/aa995748(v=exchg.65).aspx

钉子

1\对数据库进行碎片整理是减小数据库的方法之一，但是数据库是否有空白空间可以被整理出，可以事先通过事件ID1221，进行分析。
2\对数据库整理时，会同时对edb和stm文件进行整理。
3\更多信息建议参考，提供的相关信息


====

数据库碎片整理的作用和注意事项

运行中的Exchange Server会根据管理员指定的时间在后台不断地进行在线碎片整理（Online Defrag）。在线碎片整理主要执行如下的操作：

1.通过查询活动目录来确定Store中是否有被删除的邮箱。
2.物理的删除所有超过保留时间的邮件和邮箱。
3.执行在线碎片整理。

对于第一项操作，Exchange Server会向活动目录发起查询，以确保活动目录中的用户信息和Exchange Store中保存的邮箱信息是同步的，对于删除的邮箱，Exchange Server会作特殊的标记。这项操作不会对Exchange Server带来太多的额外负担，但是对活动目录的域控制器却有一定的压力。一般我们是在晚上进行在线碎片整理的操作，所以此时活动目录的负载不会有什么问题，但如果对于一些大型的跨国企业，其活动目录的域控制器往往要服务于各时区的用户时，在线碎片整理的时间需要认真地调整以避免给用户带来影响。

第二和第三项操作会对Exchange Server本身带来一定的负载，主要是一些密集的磁盘操作。在线碎片整理期间，用户访问邮箱的速度会明显的变慢。当Exchange Server的备份和在线碎片整理的时间发生冲突时，在线碎片整理会被终止并直到备份完成才能得以恢复。关于在线碎片整理的详细细节，请参考微软知识库文档“Understanding Performance and Scalability Characteristics of Exchange 2000 MDB Online Maintenance”，其文档代号为271222。

正常情况下，在线碎片整理会在管理员规定的时间停止，并在事件日志中记下如下的内容

Event: 1221
Source: MSExchangeIS Private
Type: Information
Category: General
Description: The database has nnn megabytes of free space after online defragmentation has terminated.  


这表示Exchange Server在线碎片整理过程中发现并计算出数据库中含有的碎片空间的大小。在线碎片整理只会标示出碎片的位置并计算其空间，并不会物理的移动数据页面以消除这些碎片空间。如果需要物理的消除这些碎片空间，需要执行离线碎片整理。当上面事件中显示的碎片空间达到一定的比例时（占数据库文件的10%~15%），我们需要执行离线碎片整理。

对于离线碎片整理，我们通常按照如下的流程：

1.在进行离线碎片整理之前，对所操作的Store进行全备份
2.Dismount Store
3.使用eseutil /mh确认edb和stm文件是“Clean shutdown”（在上期中有详细的论述）
4.执行如下的命令来进行碎片整理

C:\Program Files\Exchsrvr\BIN>eseutil /d
X:\Exchsrvr\Mdbdata\SG1MS1.edb
/tX:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /o /p <回车>


命令会有如下的输出：


Initiating DEFRAGMENTATION mode...
            Database: F:\Exchsrvr\Mdbdata\SG1MS1.edb
      Streaming File: F:\Exchsrvr\Mdbdata\SG1MS1.STM
      Temp. Database: F:\Exchsrvr\Mdbdata\SG1MS1_temp.edb
Temp. Streaming File: F:\Exchsrvr\Mdbdata\SG1MS1_temp.STM

                  Defragmentation Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |-----|-----|-----|-----|-----|-----|------|------|------|------|
          .................................................................................

Note:
It is REQUIRED that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup.

Operation completed successfully in 13.110 seconds.


碎片整理的实际时间取决于数据库文件的大小，在Exchange 2000中，一般一小时可以处理7~10GB的数据。在碎片整理完成后，系统会根据制定的文件名生成两个不含碎片的edb和stm文件。

5.在把新的数据库文件Mount之前，需要确保其完整性，我们要执行如下的命令


C:\Program Files\Exchsrvr\BIN>eseutil /g X:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /sX:\exchsrvr\mdbdata\SG1MS1_temp.stm <回车>


其输出如下：


Microsoft(R) Exchange Server(TM) Database Utilities  Version 6.0
Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.

Initiating INTEGRITY mode...
        Database: priv1.edb
  Streaming File: priv1.stm
  Temp. Database: TEMPINTEG3976.EDB

Checking database integrity.
                     Scanning Status (% complete)
          0    10   20   30   40   50   60   70   80   90  100
          |-----|-----|-----|-----|-----|-----|------|------|------|------|
          .................................................................................
Integrity check successful.
Operation completed successfully in 9.62 seconds.


此项操作也需要较长的时间，一般的速度是10GB每小时。

6.文件改名。把旧的edb文件和stm文件从mdbdata文件夹中移走。把执行过碎片整理的临时文件改为同旧的edb文件和stm文件相同的名字。然后Mount数据库。
7.如果Mount数据库失败，最快的恢复办法就是把旧的edb文件和stm文件再复制到mdbdata文件夹。Defrag过程中，旧的edb文件和stm文件没有被更改，即使defrag失败，也可以恢复到defrag之前的状态。

关于碎片整理得更多细节，我们可以参考下面的文档：
192185 XADM: How to Defragment with the ESEUTIL Utility