oracle 文档说，在更改索引子句期间shrink space compact，coalesce它们非常相似，可以相互替换，但 Tom发现行为有所不同。
由于 Oracle Database 的标准版本中不提供 coalesce，因此我认为使用它有一些好处。
那么，有什么区别呢？我可以shrink space compact在动态变化的索引上执行吗？
问问题
9888 次
2 回答
5
上面的答案是错误的。基本上有4个选项。
1 - 改变索引合并
2 - 改变索引收缩空间
3 - ALTER INDEX 收缩空间紧凑
4 - 改变索引重建
选项 1 和 3 不会释放块。它们只是释放现有块中的空间。Coalesce 做得更差一点，会有更多的块只有 25-50% 的可用空间，而收缩空间紧凑，会有更多的块有 75-100% 的可用空间。但是，块的总数保持不变。例如，一个包含 200 个块的索引合并后，在随机删除 1/5 的行之后，大约 1/5 的索引块有 25-50% 的可用空间，而其余的保持满。
另一方面，收缩空间和重建确实释放了块，并将它们合并到现有的块中，从而减少了块的总数。我认为唯一的区别是速度。当你从一个大表中只删除 5% 时，没有理由重建整个索引，而且会很慢。但是，这里的收缩空间可能会快一点，因为它不会重建整个索引，只是重新组织块。
显然，最快的选择是使用紧凑选项合并或缩小空间。
于 2013-12-19T09:40:25.393 回答
1
首先，索引一般不需要频繁重建。它们通常会增长到稳定的大小并保持在那里，并且重建它们只会对查询产生暂时的好处，然后由于块拆分率的增加而增加修改它们的负载来抵消这些好处。所以不要忘记，对流程的最佳优化是完全消除它——如果您认为需要频繁重建，请发布一个问题，也许可以解释原因并找到不同的方法。
无论如何，coalesce 减少了保存索引数据的块的数量，从而完全释放块，以便它们可以重新用于新的索引条目。但是，释放的块仍然分配给索引。这可以防止索引增长过大。
Shrink 做了类似的事情，但移动了填充的块，以允许从索引段的“末端”释放块被释放。因此索引段实际上变小了。这需要对表进行排他锁。
于 2013-05-20T06:37:51.477 回答