日期:2014-05-17  浏览次数:20529 次

sqlserver表碎片是如何产生的
如题 

我这么理解

比方说 有一张表 有十条数据 表的数据是递增的 我删除了第五条

那么如果用户新增一条数据的话 应该是插入第十条后面 

那么第五条的空间可能不会在被利用了 】

这样我理解为表碎片了 

请各位大牛 解答一下 感激之至!

------解决方案--------------------
这个是逻辑碎片,
碎片有区碎片和逻辑碎片,
区碎片,当需要1个数据页分成2页的时候产生
逻辑碎片就是你说的那样
------解决方案--------------------
    这么理解也还真是独特, 当表有聚集索引的时候这些会被删除的记录应该会标记为虚影,虚影记录大概60秒被一个叫什么clear的线程清除掉。这样当有用户需要这空间时就直接被利用了。这个叫索引碎片,因为聚集索引就是数据本身吗?产生碎片的主要原因就是页不完成的删除也就是一页数据100条数据只删除了60条。和分页。
    你说的这个是堆结构的表,也就是没有聚集索引的表,如果在堆上删除时获取行级或分页级锁,这些空间不被释放,那怕你删除某一页的最后一条数据。这部分空间也不会马上释放。算了我懒得打字了,直接上某论坛上的例子吧。


今天给大家分享一个”删除大量数据后SQL Server性能下降”的案例。一般而言,数据库数据减少后,应该有助于提高SQL server的整体性能。可是在这个案例中,情况恰恰相反。

 

症状

=========

-          删除大量数据后SQL Server性能下降

-          一些存储过程之前运行20分钟左右,现在需要运行2-3个小时。

 

背景信息

=========

-          大量数据通过DELETE语句而删除

-          数据删除后,客户进行了相关的维护工作 : 重建索引和更新统计数据

-          性能变慢的存储过程会对一些表做很多的”DELETE”,”INSERT”和”SELECT”操作。

 

调查

=========

-          相关的表都是堆( heap table)

 

-          这些表中并没有大量数据

 

-          DBCC CHECKCONTIG 结果显示表很大,但其页的密度 (Page Density) 却相当小。

 

DBCC SHOWCONTIG scanning 'tblA' table...

Table: 'tblA' (322816212); index ID: 0, database ID: 14

TABLE level scan performed.

- Pages Scanned................................: 1779939 à13.6GB

- Extents Scanned..............................: 223475

- Extent Switches..............................: 223474

- Avg. Pages per Extent........................: 8.0

- Scan Density [Best Count:Actual Count].......: 99.56% [222493:223475]

- Extent Scan Fragmentation ...................: 23.65%

- Avg. Bytes Free per Page.....................: 8059.1

- Avg. Page Density (full).....................: 0.43%

 

DBCC SHOWCONTIG scanning 'tblB' table...

Table: 'tblB' (1005246636); index ID: 0, database ID: 14

TABLE level scan performed.

- Pages Scanned................................: 215600 à1.6GB

- Extents Scanned..............................: 27269

- Extent Switches.......................