sql - 压缩，碎片整理，回收空间，收缩数据库与收缩文件

Question

[1]指出:

“从堆中删除数据时，页面上的数据不会被压缩(回收)。并且应该删除堆页面的所有行，通常无法回收整个页面”

“ALTER INDEX重建和重组选项不能用于对堆中的空间进行碎片整理和回收(但它们可以用于对堆中的非聚集索引进行碎片整理)。
如果要在SQL Server 2005中对堆进行碎片整理，则有以下三种选择:

1)在堆上创建一个聚集索引，然后删除该聚集索引；

2)使用SELECT INTO将旧表复制到新表；或

3)使用BCP或SSIS将数据从旧表移动到新表。
在SQL Server 2008中，更改了ALTER TABLE命令，因此它现在具有重建堆的能力”

请给我解释一下:
MS SQL Server 2005中的压缩，碎片整理，回收空间，收缩文件和收缩数据库之间有什么区别？
收缩文件和收缩数据库在MS SQL Server 2005中完成什么工作？

更新:
这个问题是受到[2]中讨论的启发-如何在MS SQL Server 2005中缩小数据库？

Update2: @PerformanceDBA，
ga!您在短短一周内就获得了500多种收益。这太了不起了!

你的图
再次感谢您的宝贵时间。
我待会再问，不在这里。
内在不是我最主要的事情，也不是最简单的事情。

它非常简洁，一般来说，颂歌不会引起任何疑问或疑问。

我希望使用一些工具，描述/说明，技术来提出自己的疑问，问题和讨论。
例如，请看我的问题:

http://www.sqlservercentral.com/Forums/Topic1013693-373-2.aspx#bm1014385

http://www.sqlservercentral.com/Forums/Topic1013975-373-1.aspx

它们基本上是我所要求的内容的重复内容，但不能在stackoverflow.com中进行讨论

Update3: @PerformanceDBA，
再次感谢，我的问题的主要目的是确定解决具体问题的方法(基于和避免出现什么问题)，这些问题包含您发现的矛盾文档，文章，讨论，答案等。

目前，我在这方面没有其他问题(无法解决且无法解决)。

[1]
布拉德·麦基(Brad McGehee)。布拉德肯定的索引指南
(2009年6月11日)
http://www.simple-talk.com/sql/database-administration/brads-sure-guide-to-indexes/
[2]
问题的答案和反馈
“将数据库缩小到其初始大小以下”
https://stackoverflow.com/questions/3543884/shrink-a-database-below-its-initial-size/3774639#3774639

Answer 1

一个多月没有人碰过这个。

前三个答案的答案实际上在 Diagram I Made for You 中，您无需费心去消化和询问有关……的问题，它通常用作讨论的平台。

(That is a condensed version of my much more elaborate Sybase diagrams, which I have butchered for the MS context. There is a link at the bottom of that doc, if you want the full Sybase set.)

因此，我也不会花太多时间在你身上。而且，请不要要求链接到“参考站点”，没有这样的东西(可用的是非技术垃圾)，这就是为什么我有自己的图表；很少有人了解MS SQL Internals。

回收空间

那是正确的术语。 MS不会从页面中删除已删除的行，也不会从扩展区中删除已删除的页面。回收空间是一项通过堆操作并删除未使用的(a)行和(b)页面的操作。当然，这会更改RowId，因此必须重新构建所有非聚集索引。

压缩

在粘贴的文本中:与回收空间相同。

碎片整理

全面清除未使用空间的操作。共有三个级别:

一，数据库(AllocationUnits)，跨所有对象

二。对象(范围和页面)，页面链，拆分页面，溢出页面

三，仅堆(无聚集索引)，该帖子的主题

收缩文件

完全不同的操作，以减少在设备(文件)上分配的空间。这将删除未使用的AllocationUnits(因此“缩小”)，但是对碎片整理的AllocationUnits有所不同。

收缩数据库

对数据库执行相同的操作；数据库在所有设备上使用的所有设备分配。

对评论的回应

SSC的发布者毫无头绪，不会直接解决您的问题。

没有集群表(CREATE CLUSTERED TABLE失败)之类的东西。

有诸如聚集索引(CREATE CLUSTERED INDEX成功)之类的东西。
按照我的图表，

是一个物理结构；聚集索引包含行，因此消除了堆

没有聚集索引，它有两个物理结构:堆和单独的非聚集索引

现在，在您使用DBCC入门之前，DBCC的级别太低，无知的人们无法识别，更不用说解释其原因和原因了，您需要了解并确认上述内容:

创建一个Table_CI(我们打算添加一个CI，仍然没有诸如簇表之类的东西)

向其添加唯一的聚集索引UC_PK

添加几行

创建表堆

向其添加唯一的非聚集索引NC_PK

添加几行

SELECT * FROM sysindexes，其中id = OBJECT_ID(“Table_CI”)

SELECT * FROM sysindexes，其中id = OBJECT_ID(“Heap”)

注意，每个sysindexes条目都是一个完整的，独立的数据存储结构(请看各列)

考虑输出

与我的图表进行比较

与宇宙中的垃圾进行比较

将来，我将不再回答有关宇宙中混乱的垃圾以及其他站点上不正确和错误消息的帖子的问题(我不在乎他们是否是MS认证专家，他们证明他们无力检查自己的数据库并确定正确的信息)

我费心创建准确的图表是有原因的(MS的手册，图片和所有可用信息都是乱七八糟的；对于您没有必要从:authority查找准确的信息，因为“authority”从技术上讲是正确的)破产)。

甚至盖尔终于到处走走
我怀疑在摆弄底层内部知识之前，您将从更多的索引总体体系结构中受益。

除了，没有任何东西。这不会造成混淆，非技术性和不一致。

我费心创建准确的图表是有原因的。

返回到DBCC。盖尔是完全不正确的。在聚集索引(包括行)中，单个页面包含行。是的，行。那就是索引的叶子级别。有一个B树，它位于页面顶部，但是它很小，您看不到它。查看sysindexes输出。根和首页指针指向页面；这是聚簇索引的根。当您潜入海洋时，您需要知道要寻找的东西以及在哪里可以找到它，否则您将找不到想要的东西，并且您会因自己偶然发现的漂浮物和喷射物质而分心。

现在看一下NCI和堆的两个单独的结构。

哦，MS已经从使用OAM术语更改为以数据结构为索引的IAM。这带来了混乱。就数据结构(sysindexes中的条目)而言，它们都是对象。它们可能是也可能不是索引)。关键是，谁在乎，我们知道它是什么，它是一个ObjectAllocationMap……如果您正在看NCI，gee，它是一个IndexObjectAllocationMap；如果您正在查看堆，则为HeapObjectAllocMap。我将考虑使用CI时的情况。在追踪或使用它时(找到属于该对象的页面并不重要，它们都是对象。这样做时，您需要知道，某些对象具有PageChain，而其他对象则没有PageChain(另一个您的问题)。配置项拥有它们； NCI和堆没有。

盖尔·肖(Gail Shaw):“我怀疑这些内部结构是否在任何地方都有记录。毕竟，我们使用的是未记录的功能。索引的定义取决于您询问的人和外观。

ROTFLMAO。我的两面都受伤了，我看不清其后的帖子。这些应该是聪明的人吗？在IT世界中工作？定义CHANGE？什么温度或一天中的什么时间？那就是SQL Server Central？不是偏僻地区吗？

当MS从Sybase窃取SQL Server时，该文档非常可靠。当然，在每个主要发行版中，他们都“重写”了该文档，文档变得越来越虚弱和蓬松(回想一下我们在另一篇文章中的讨论)。现在，从技术上讲，我们拥有可爱的照片，可以使人感觉良好但不准确。这就是为什么像你这样认真的人有问题的原因。图片甚至与手册中的文字不符。

无论如何，定义不会改变。那就是定义的定义。它们在任何情况下都是正确的。嗯，您正在使用的um功能是已记录的普通功能。自1987年以来一直如此。除非MS在某个地方丢失了它，而且没人能找到它。您将不得不询问过去的Sybase Guru，他记得他们获取的代码中确切的数据结构。而且，如果您真的很幸运，他将及时了解MoronSociety在2000年，2005年和2008年引入的差异。他甚至可能只有一个准确的图表，可以与您盒子上的sysindexes和DBCC的输出相匹配。如果找到他，请亲吻他的戒指，并给他淋浴。锁上你的女儿们。

(不严重，我的身边正在杀死我，欢乐满溢)。

现在您知道为什么我不回答有关宇宙中混乱垃圾的问题吗？在MoronSociety中，有很多白痴。

-----

再次盖尔:

“扫描:
索引扫描是对索引中所有叶子页的完整读取。当对聚集索引 进行索引扫描时，除了名称以外，它都是表扫描。
当查询处理器完成索引扫描时，无论是否返回所有行，它始终是索引中所有叶子页的完整读取。这绝不是部分扫描。
扫描不仅涉及读取索引的叶级别，还读取较高级别的页面作为索引扫描的一部分。”

她以快风而得名是一定有原因的。她写“书”吗？是的，幻想小说。热风是为气球爱好者提供的，而不是IT专业人员。

完整和完整的文件。索引扫描的全部要点以及为什么它适合表扫描，因为它正试图避免表扫描，因此:
-引擎(执行查询树)可以直接转到索引(此时为聚集或非聚集)
-导航到B树以查找开始的位置(到现在为止，该位置与获取几行(即不扫描)大体相同)
-B树(从任何良好的TECHNICAL图表来看)只有几页，每页包含许多索引条目，因此它非常快
-这是根加非叶水平
-直到找到符合条件的叶级条目
-从那时起，它依次通过所述索引的LEAF级别进行扫描(胖蓝色箭头)

现在针对NCI的

，如果您还记得自己的作业，则意味着叶子级页面上充满了index_leaf_level_entry + CI_key

，因此它将在NCI叶级别上顺序扫描(这就是为什么仅在NCI的叶级别上存在PageChain，以便它可以浏览的原因)

，但在HEAP上到处跳转，以获取数据行

，但对于CI，叶级是数据行(数据页，仅包含数据行，这就是为什么您看不到其中的“索引”的原因；非叶级CI页是仅包含index_entries的纯索引页)

，所以当它使用PageChain顺序扫描索引leaf_level时，它顺序扫描数据，它们是相同的操作(绿色绿色箭头)

no堆

不能绕过

为了进行比较，然后使用表扫描(仅MS):
-堆上没有PageChain
-别无选择，只能从头开始
-并读取每个数据页
-其中许多将分散(包含已删除或转发的行留下的未使用空间)
-而其他人将完全是空的

整个意图是，优化器已经决定不进行表(堆)扫描，而是可以进行索引扫描(因为它需要的数据比整个数据范围少，并且可以找到数据的起点)通过某个索引获取该数据)。如果您查看SHOWPLAN，即使是检索一个唯一的PK行，它也会显示“INDEX SCAN”。这意味着，它将首先导航B-树，以找到至少一行。然后，它可能会扫描叶级别，直到找到终点。如果是覆盖查询，则永远不会转到数据行。

不能代替聚簇索引。