Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

65

积分

0

好友

31

主题
1#
发表于 2013-2-17 03:06:51 | 查看: 7432| 回复: 14
网上资料都说
对于OLAP系统 DB_BLOCK_SIZE越大越好。

假设现在 DB_BLOCK_SIZE 一个是 8k,一个是32K
如果一个表的数据是64K
那么现在抓取一份全表数据
当DB_BLOCK_SIZE=8K时, 需要读取8个block
当DB_BLOCK_SIZE=32K时, 需要读取2个block
所以这个时候读取的效率高
但是请注意
8个block并不等于8次IO
2个block并不等于2次IO

   
假设一次IO的读写能力是64k
那么无论DB_BLOCK_SIZE是多少又有何区别呢?

而且数据分布无非两种场景,
一种是连续分布,一种是不连续分布

假设数据是连续的,无论data block的size是多少,读取64K的数据反正都是1个IO

如果数据不连续,那么极端情况,假设这个表有100条记录
那么着100条记录有可能分布在100个data block上
那么这个时候,杯具的事情发生了,
对于 8k的数据块要抓取100个data block
对于32k的数据块也要抓100个data block,那么这时谁的效率高呢?
很明显。当然还是8k的data block高。
实在看不出DB_BLOCK_SIZE越大为何对OLAP系统有好处
2#
发表于 2013-2-17 09:07:48
关注!


回复 只看该作者 道具 举报

3#
发表于 2013-2-17 14:04:50
有点意思

回复 只看该作者 道具 举报

4#
发表于 2013-2-17 14:06:35
有点意思

回复 只看该作者 道具 举报

5#
发表于 2013-2-17 14:33:14
这个问题 可以从几个方面分析:

1. 首先OTAP 用大block size,这个只是一家之言 , 并非 金科玉律
2.  block管理 本身需要 一些overhead , 例如block header这些, 当block size变大,这些管理数据的损耗变小,则同样的space可以存放更多的数据,有助于数据瘦身和 全表扫描等操作

可以从更多角度分析这个问题,我抛砖引玉一下

回复 只看该作者 道具 举报

6#
发表于 2013-2-17 14:50:02
我认为是 在OLAP 分析系统 往往是select 和INSERT INTO  大数据量的统计和大数量的插入.
假如说 100条记录,每条记录占有1K的数据空间   8K的数据块除掉头尾部 能提供7K数据空间,那么能存放7条记录  100/7=14个块
32K数据块 能存放31条记录   100/31=4个块.

回复 只看该作者 道具 举报

7#
发表于 2013-2-17 14:51:43
如果多块读参数 设置为4   那么对于8K的话 要读4次IO  对32K来说 就只要1次IO.                 

回复 只看该作者 道具 举报

8#
发表于 2013-2-17 20:56:23
zengmuansha 发表于 2013-2-17 14:51
如果多块读参数 设置为4   那么对于8K的话 要读4次IO  对32K来说 就只要1次IO.                  ...

那如果把 db_file_multiblock_read_count 设置到最大,即保持

Max(db_file_multiblock_read_count) = MaxOsIOsize/db_block_size
这样的关系,那么
那么无论对于8K还是对于32K,那IO的次数不都还是一样的吗?

回复 只看该作者 道具 举报

9#
发表于 2013-2-17 21:01:51
zengmuansha 发表于 2013-2-17 14:50
我认为是 在OLAP 分析系统 往往是select 和INSERT INTO  大数据量的统计和大数量的插入.
假如说 100条记录, ...

如果考虑数据块中的管理域部分,即metadata部分,因为这部分大小是固定,和数据块大小没有关系,这个角度来说,确实更大的DB_BLOCK_SIZE能够存放的实际业务数据会更多,但是我的问题是
假设以10万条记录而言,这个管理域部分的影响大吗?
是否可忽略不计啊?我所谓忽略不计的意思,

假设对于db_block_size为32K的datablock,读10万条记录,需要60秒
     对于db_block_size为8K的datablock,读10万条记录,需要65秒
仅仅多出5秒,等于效率只差了12分之一,勉强,还是可以接受吧?

回复 只看该作者 道具 举报

10#
发表于 2013-2-18 14:30:54
你这时间假设这角度不好说.  你从多次IO来算
比如说10万条记录 每条记录占有1K的数据空间  8K的数据块除掉头尾部 能提供7K数据空间,那么能存放7条记录 10万条记录/7 =1,4286
32K数据块 能存放31条记录   10万/31=3226个块.

db_file_multiblock_read_count  一般设置为16或者32
如果全表扫描的话 8K=>1,4286/16=893次IO     ;  32K=>3226/16=202次IO
再存储IO能力大于情况下,小块在全表扫描下是浪费IO能力.

另外就是db_file_multiblock_read_count 设置成最大值,虽然会一样的. 可内存中的BUFFER的BUFF块的数量 32K的话 会比8K的数量少很多. 访问BUF桶 BUF连 BUF栓锁 也消耗资源少.

从物理读和逻辑读 都是有优势的.

回复 只看该作者 道具 举报

11#
发表于 2013-2-19 13:51:42
http://www.itpub.net/thread-1498543-1-1.html

回复 只看该作者 道具 举报

12#
发表于 2013-2-20 08:51:19
zengmuansha 发表于 2013-2-18 14:30
你这时间假设这角度不好说.  你从多次IO来算
比如说10万条记录 每条记录占有1K的数据空间  8K的数据块除掉 ...

确实澄清我过往的一个意识,因为过去讲DB_BLOCK_SIZE越大,读相同连续分布的记录需要的IO就越少
,所以通常OLAP系统选择大的DB_BLOCK_SIZE,但是这个确实取决于db_file_multiblock_read_count这么一个参数,但是只要这个参数足够大,即无论DB_BLOCK_SIZE是8k还是32K
都满足DB_BLOCK_SIZE*db_file_multiblock_read_count=MAXIOSIZE的时候,其实这个时候需要去考虑数据块的元数据部分,因为无论块大小,元数据部分大小一般是确定,所以32K的数据块存储的业务数据实际是比4个8k的数据块要多的。

另外你还提醒我了内存中BUFFER header数目的不同。达人啊

回复 只看该作者 道具 举报

13#
发表于 2013-2-20 10:32:15
etl2007 发表于 2013-2-20 08:51
确实澄清我过往的一个意识,因为过去讲DB_BLOCK_SIZE越大,读相同连续分布的记录需要的IO就越少
,所以通 ...

所谓 逻辑读 呵呵! 要加LATCH锁

回复 只看该作者 道具 举报

14#
发表于 2013-2-20 15:09:37
本帖最后由 wind 于 2013-2-20 15:12 编辑
zengmuansha 发表于 2013-2-18 14:30
你这时间假设这角度不好说.  你从多次IO来算
比如说10万条记录 每条记录占有1K的数据空间  8K的数据块除掉 ...


嗯,有见地。也学了东西。

看来olap系统block_size设大,还是有道理的,利大于弊啊。

就两点:

1. io 次数
2. buffer cache,latch啊

考虑了逻辑读

回复 只看该作者 道具 举报

15#
发表于 2013-2-23 14:23:49
个人理解,OLAP系统的IO比较大的情况下,一次读取的多个BLOCK大小越大,所需要的时间就会越短吧。

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-16 08:50 , Processed in 0.053315 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569