如何避免SHRINKDATABASE & SHRINKFILE 产生索引碎片（转载）
1. TRUNCATEONLY参数的使用
我们在建立的Job中通常使用如下的语法
DBCC SHRINKDATABASE (N'DB', 10,TruncateOnly)
其中TruncateOnly的用处是把：“将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动”，
所以此时前面指定的“10”（target_percent），将不起作用，由于删除数据等作业导致的大量的空闲的数据页，将不会被回收，上面的语句的作用，只能把文件结尾部分有限的空闲数据页回收。也就不能完全达到数据库收缩的作用了。
建议的做法如下：
先通过DBCC SHRINKDATABASE (N'DB', 10) WITH NO_INFOMSGS 对数据文件中的数据页进行整理，
然后再通过dbcc shrinkfile(DB_Data, truncateonly)
dbcc shrinkfile(DB_Log, truncateonly)
分别对数据库数据文件和Log文件收缩，这样可以真正达到数据库收缩的目的
2. Index的重建
通常我们对数据库进行收缩后会增加Index的碎片的产生，同时也就降低了数据的查询速度。
我们可以通过下面的Script，查看Table的索引的状况
DBCC SHOWCONTIG(ipprhm) WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'ipprhm' table...
Table: 'ipprhm' (1009438670); index ID: 1, database ID: 15
TABLE level scan performed.
- Pages Scanned................................: 13746
- Extents Scanned..............................: 1732
- Extent Switches..............................: 3179
- Avg. Pages per Extent........................: 7.9
- Scan Density [Best Count:Actual Count].......: 54.06% [1719:3180]
- Logical Scan Fragmentation ..................: 67.92%
- Extent Scan Fragmentation ...................: 57.16%
- Avg. Bytes Free per Page.....................: 2177.7
- Avg. Page Density (full).....................: 73.09%
DBCC SHOWCONTIG scanning 'ipprhm' table...
Table: 'ipprhm' (1009438670); index ID: 15, database ID: 15
LEAF level scan performed.
- Pages Scanned................................: 79
- Extents Scanned..............................: 18
- Extent Switches..............................: 21
- Avg. Pages per Extent........................: 4.4
- Scan Density [Best Count:Actual Count].......: 45.45% [10:22]
- Logical Scan Fragmentation ..................: 7.59%
- Extent Scan Fragmentation ...................: 83.33%
- Avg. Bytes Free per Page.....................: 1397.4
- Avg. Page Density (full).....................: 82.73%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
我们在建立的Job中通常使用如下的语法
DBCC SHRINKDATABASE (N'DB', 10,TruncateOnly)
其中TruncateOnly的用处是把：“将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动”，
所以此时前面指定的“10”（target_percent），将不起作用，由于删除数据等作业导致的大量的空闲的数据页，将不会被回收，上面的语句的作用，只能把文件结尾部分有限的空闲数据页回收。也就不能完全达到数据库收缩的作用了。
建议的做法如下：
先通过DBCC SHRINKDATABASE (N'DB', 10) WITH NO_INFOMSGS 对数据文件中的数据页进行整理，
然后再通过dbcc shrinkfile(DB_Data, truncateonly)
dbcc shrinkfile(DB_Log, truncateonly)
分别对数据库数据文件和Log文件收缩，这样可以真正达到数据库收缩的目的
2. Index的重建
通常我们对数据库进行收缩后会增加Index的碎片的产生，同时也就降低了数据的查询速度。
我们可以通过下面的Script，查看Table的索引的状况
DBCC SHOWCONTIG(ipprhm) WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'ipprhm' table...
Table: 'ipprhm' (1009438670); index ID: 1, database ID: 15
TABLE level scan performed.
- Pages Scanned................................: 13746
- Extents Scanned..............................: 1732
- Extent Switches..............................: 3179
- Avg. Pages per Extent........................: 7.9
- Scan Density [Best Count:Actual Count].......: 54.06% [1719:3180]
- Logical Scan Fragmentation ..................: 67.92%
- Extent Scan Fragmentation ...................: 57.16%
- Avg. Bytes Free per Page.....................: 2177.7
- Avg. Page Density (full).....................: 73.09%
DBCC SHOWCONTIG scanning 'ipprhm' table...
Table: 'ipprhm' (1009438670); index ID: 15, database ID: 15
LEAF level scan performed.
- Pages Scanned................................: 79
- Extents Scanned..............................: 18
- Extent Switches..............................: 21
- Avg. Pages per Extent........................: 4.4
- Scan Density [Best Count:Actual Count].......: 45.45% [10:22]
- Logical Scan Fragmentation ..................: 7.59%
- Extent Scan Fragmentation ...................: 83.33%
- Avg. Bytes Free per Page.....................: 1397.4
- Avg. Page Density (full).....................: 82.73%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
从上面的结果可以看出，扫描密度比较低和逻辑扫描碎片比较高，所以需要进行Index碎片整理。
整理Index的方式有两种：
DBCC INDEXDEFRAG(DB, TABLE, INDEX) WITH NO_INFOMSGS 和
DBCC DBREINDEX(TABLE, '', 0)
INDEXDEFRAG是在线重整Index，不会对Table锁定，但是由于INDEXDEFRAG是对Index的重组，所以Index的数据页不一定是连续的。
DBREINDEX会对Table进行锁定，重建索引。
