奇怪的表空间碎片和表的记录存贮问题

fals · 发表于 2003-2-9 21:21

最初由 4pal 发布
[B]

我想，只有当分配extent的时候才影响性能。读取的时候，应该没又影响 [/B]

我对这个问题的理解是这样的：
对于读表来讲，按biti兄的说法来讲，一次IO最大读取的数据量不可能超过操作系统的能力。在实际的表查询过程中，一个查询语句要获得的数据存放的位置，有可能是在一个块内，有可能在一个段里，有可能在多个分区里，oracle是不可能预测到的。那么平均起来，我猜想一般情况下的读表动作，可能是东取一点西找一点数据的。这种情况下表的数据在硬盘上是否连续存放，确实意义不大。
在分配extent的时候，oracle则需要寻找哪一个extent符合要求的大小。如果碎片大小不一，则这个寻找过程可能就很费时。但如果表空间里的碎片大小是一样的，而且又都符合表的extent的大小呢？就象我做的测试那样？我想这个时候的分配extent也不会太影响性能。

从另一个角度来理解Feng兄的解释，也考察一下我做的测试时oracle分配的extent的顺序，虽然说没有什么规律，但还是可以看到，oracle是先分配已有的碎片，而不是在一个最大的自由空间里再开一块出来，这是一；另一方面，分配的extent的起始块号也是从小到大的，只有快到了碎片的末尾了，才又回过头来再分配前面的碎片。当然，这只是很短时间内连续的向一个表里插入大量数据的结果，如果是并发访问多个表里插入数据的情况，可能又会不一样的。我只是觉得，Feng兄提到的，从物理的角度来理解oracle的分配，可能还是可以这样解释的。

parrotao · 发表于 2003-2-10 14:37

看看这个
http://www.itpub.net/showthread. ... 60&pagenumber=3

结果集大这个提醒帮了我，应用方面逻辑读数量巨大是事实，但是结果集是大了些，后来终于找到原因了。我观察了一下tablespace的利用，将近80%，根据对方dba说，不应该有这么多数据，怀疑是碎片，exp/imp后，压缩成10％，结果现在运行相当平稳，cpu idle平均30%，基本满足要求。

chao_ping · 发表于 2003-2-10 15:03

碎片 <> 多个Extent

多个Extent不影响性能,但是严重的碎片的确影响性能. 比如不合理的PCTUsed和大量Delete等.
索引的低效率, HWM的很高等.

parrotao · 发表于 2003-2-10 15:08

我知道呀
碎片 <> 多个Extent
可是这里是在谈碎片吧?

4pal · 发表于 2003-2-10 15:28

ft，此碎片非彼碎片啊

一个指block内的碎片（空隙）
另外一个指不连续的block吧？
楼主应该想问的是后者吧？

fals · 发表于 2003-2-10 19:37

最初由 4pal 发布
[B]ft，此碎片非彼碎片啊
[/B]

在这个测试中，形成的所谓“碎片”并不是通常oracle说的碎片，实际上更准确的说应该是磁盘碎片。
实际上，在这个测试中是形成了多个大小相等的extent，而并不是在一个extent中数据存放以后还有空闲的块。
关于在一个extent中有大量碎片的问题，应该是biti兄研究过的在一个段内进行空间分配的问题，现在讨论的应该是在一个表空间内oracle对段的分配问题。

应该是讨论的这个吧？

aaahhh · 发表于 2003-2-11 06:10

对于数据库碎片盖棺定论的文章(不包括9i)
http://www.dbatoolbox.com/WP2001/spacemgmt/frag.pdf

jlandzpa · 发表于 2003-2-13 08:59

那位高人给翻译翻译！

最初由 aaahhh 发布
[B]对于数据库碎片盖棺定论的文章(不包括9i)
http://www.dbatoolbox.com/WP2001/spacemgmt/frag.pdf [/B]

whuijun · 发表于 2003-2-17 13:05

继续关注！！

[精华] 奇怪的表空间碎片和表的记录存贮问题

浏览过的版块