如何避免SHRINKDATABASE & SHRINKFILE 产生索引碎片(转载)

时间:2021-07-01 15:45:52
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.
 
从上面的结果可以看出,扫描密度比较低和逻辑扫描碎片比较高,所以需要进行Index碎片整理。
整理Index的方式有两种:
DBCC INDEXDEFRAG(DB, TABLE, INDEX) WITH NO_INFOMSGS 和
DBCC DBREINDEX(TABLE, '', 0)
 
INDEXDEFRAG是在线重整Index,不会对Table锁定,但是由于INDEXDEFRAG是对Index的重组,所以Index的数据页不一定是连续的。
DBREINDEX会对Table进行锁定,重建索引。