如何使用 Eseutil 实用工具 进行碎片整理

可以使用 Eseutil 实用工具对 Exchange Server 5.5 中的信息存储和目录进行碎片整理，以及对 Exchange 2000 Server 中的信息存储进行碎片整理。Eseutil 在数据库的低层(Ese.dll)对数据库表的结构进行检查和记录（可能包括读取、扫描、修复和碎片整理）。

Eseutil 位于 Exchange Server 5.5 的 Winnt\System32 文件夹中以及 Exchange 2000 的 Exchsrvr/Bin 文件夹中。每次可以从命令行中对一个数据库运行该实用工具。

碎片整理选项可以使已用存储保持连续，消除未使用的存储，压缩数据库（这可以降低数据库的大小）。Eseutil 将数据库记录复制到新数据库。完成碎片整理后，将删除原始数据库或将其保存到用户指定的位置，并使用原始版本的名称重命名新版本。如果实用工具遇到错误记录，它将停止并显示错误信息

MDFScan数据库碎片文件扫描恢复软件用来恢复那些被认为无法恢复的MDF数据库文件，当FAT32删除或者格式化文件或者NTFS分区 里面删除文件后文件长度变成0字节，一般的数据恢复技术手段就无法完成的找回原来数据库文件的碎片数据，恢复的文件往往无法附加到数据库中。因为MDF数据库文件一般都比较大，在磁盘中往往被存放到不连续的逻辑簇中，就形成了文件碎片，当删除或者格式化后，这些分散在磁盘中的碎片数据很难恢复，这是一项公认为高难度的数据，一般的专业数据恢复人员都只能放弃这种文件。MDFScan软件的出现提供了一种理想的解决方案，我们的数据恢复软件对这个分区或者镜像文件进行扫描，压缩后的磁盘数据存入一个扩展名为mdfmf格式的文件， 将文件发给我们工程师进行重组分析，把各个碎片数据进行海量计算重组恢复，修复好数据库后便可直接附加到MS SQL企业管理器中。

SQLServer提供了一个数据库命令——DBCC SHOWCONTIG——来确定一个指定的表或索引是否有碎片。

示例：

显示数据库里所有索引的碎片信息

DBCC SHOWCONTIG WITH ALL_INDEXES

显示指定表的所有索引的碎片信息

DBCC SHOWCONTIG (authors) WITH ALL_INDEXES

显示指定索引的碎片信息

DBCC SHOWCONTIG (authors,aunmind)

DBCC 执行结果：

扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。

扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。

扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。

每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。

扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。

逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。

扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。

每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。

平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。

解决碎片问题 ：

1. 删除并重建索引

2. 使用DROP_EXISTING子句重建索引

3. 执行DBCC DBREINDEX

4. 执行DBCC INDEXDEFRAG

删除并重建索引 ：

用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不在可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。

删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。

使用DROP_EXISTING子句重建索引 ：

为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。

除了和上一个方法一样的好处之外，该方法的好处是不必重建非聚集索引两次。这样可以对那些带约束的索引提供正确的索引定义以符合约束的要求。

执行DBCC DBREINDEX ：

DBCC DBREINDEX类似于第二种方法，但它物理地重建索引，允许SQLServer给索引分配新页来减少内部和外部碎片。DBCC DBREINDEX也能动态的重建带约束的索引，不象第二种方法。

DBCC DBREINDEX的缺陷是会遇到或引起阻塞问题。DBCC DBREINDEX是作为一个事务来运行的，所以如果在完成之前中断了，那么你会丢失所有已经执行过的碎片。

执行DBCC INDEXDEFRAG ：

DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引键的逻辑顺序，通过重新整理索引里存在的叶页来减少外部碎片，通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。它不会遇到阻塞问题但它的结果没有其他几个方法彻底。这是因为DBCC INDEXDEFRAG跳过了锁定的页且不使用任何新页来重新排序索引。如果索引的碎片数量大的话你也许会发现DBCC INDEXDEFRAG比重建索引花费的时间更长。DBCC INDEXDEFRAG比其他方法的确有好处的是在其他过程访问索引时也能进行碎片整理，不会引起其他方法的阻塞问题。

---