(digest from It_pub)
rebuild时也会使用临时表空间
ask tom上关于rebuild index 有这么一段话:
If you need to rebuild your indexes, you need 2x the space -- you'll have the old and the new index for a period of time. If you do it online, you'll need additional space to hold the changes that are made during the rebuild as well
2×的空间是当前index所在的tablespace中使用空间
以前有人问过类似的问题
rebuild index为何要排序
我们都知道索引是有序的存储
然而在block内部,实际上索引键值的存储是无序的
比如说,你先存入了1,3
即使以后增加了一个2
那么在同一个数据块内部,数据库也不会去动1,3的存储
在读取的时候,oracle可以作简单的块内排序,进行有序的读取输出
在重建索引的时候
Oracle显然不会按照1,2,3..........的索引顺序来读出索引内容
因其代价高昂
Oracle实际执行的是Fast Full Scan
按顺序读取block
这样读取出来的数据需要重新sort
排序,然后重构索引
这个重构的索引在物理存储上比原来更为有序
这个可以通过block dump观察到
建立索引实际上是排序,大型的排序(只要sort area容纳不下)就要使用临时表空间
rebuild时也会使用临时表空间
ask tom上关于rebuild index 有这么一段话:
If you need to rebuild your indexes, you need 2x the space -- you'll have the old and the new index for a period of time. If you do it online, you'll need additional space to hold the changes that are made during the rebuild as well
2×的空间是当前index所在的tablespace中使用空间
以前有人问过类似的问题
rebuild index为何要排序
我们都知道索引是有序的存储
然而在block内部,实际上索引键值的存储是无序的
比如说,你先存入了1,3
即使以后增加了一个2
那么在同一个数据块内部,数据库也不会去动1,3的存储
在读取的时候,oracle可以作简单的块内排序,进行有序的读取输出
在重建索引的时候
Oracle显然不会按照1,2,3..........的索引顺序来读出索引内容
因其代价高昂
Oracle实际执行的是Fast Full Scan
按顺序读取block
这样读取出来的数据需要重新sort
排序,然后重构索引
这个重构的索引在物理存储上比原来更为有序
这个可以通过block dump观察到
建立索引实际上是排序,大型的排序(只要sort area容纳不下)就要使用临时表空间
我作了两个试验。
我的index大小为7M左右。
首先,我将index所在的tablespace只开到10M,临时表空间较大,
rebuild 时报无法在index所在的tablespace上扩展temp 段。
将表空间增大,rebuild成功。(至少要开到20M)
在将临时表空间只开到5M,表空间开到20M,rebuild就报无法在temp表空间上扩展(这个是因为需要排序,而sort area容不下,所以要利用临时表空间),将临时表空间增大到10M,rebuild成功。
1.索引的存储是,块内无序,块间有序
2.rebuild index时对于索引块的读取也是Fast full scan
3.不是说读索引的代价高,是说顺序读取块内无序的索引的代价高
所以会采用Fast Full Scan方式读取