通过案例学调优之--Oracle参数(db_file_multiblock_read_count)

简介:

应用环境:

操作系统: RedHat EL55

Oracle:   Oracle 10gR2

  Oracle DB_FILE_MULTIBLOCK_READ_COUNT是Oracle比较重要的一个全局性参数,可以影响系统级别及sessioin级别。主要是用于设置最小化表扫描时Oracle一次按顺序能够读取的数据块数。通常情况下,我们看到top events中的等待事件db file scattered read时会考虑到增加该参数的值。

1、参数DB_FILE_MULTIBLOCK_READ_COUNT(MBRC)
       参数DB_FILE_MULTIBLOCK_READ_COUNT简写为(MBRC)。
       该参数是最小化表扫描的重要参数,用于指定Oracle一次按顺序能够读取的数据块数。理论上该值越大则能够读取的数据块越多。
       实现全表扫描,索引全扫描及索引快速扫描所需的I/O总数取决于该参数,以及表自身的大小,是否使用并行等等。
       Oracle 10gR2以后会根据相应的操作系统及buffer cache以最优化的方式来自动设定该参数的值。通常情况下该值为1MB/db_block_size。
       在最大I/O为1MB的情况下,block的大小为8KB,则参数的值为128。如果在最大I/O为64KB,block为8KB,则参数的值为8。

       对于OLTP和batch环境该参数的值为4到16,DSS环境应设置大于16以上或大的值。
       该参数的变化对数据库性能产生整体性的影响,过大的设置会导致大量SQL访问路径发生变化,如原先的索引扫描倾向于使用全表扫描。
       按照Oracle的建议在10g R2之后尽可能使用oracle自动设置的值。

2、参数DB_FILE_MULTIBLOCK_READ_COUNT与SSTIOMAX
     In Release 9.2 and above; follow the explanation below:
     Each version of Oracle on each port, is shipped with a preset maximum of how much data can be transferred in a single read (which of course is equivalent to the db_file_multiblock_read_count since the block size is fixed). 
     For 8i and above (on most platforms) this is 1Mb and is referred to as SSTIOMAX.
     To determine it for your port and Oracle version, simply set db_file_multiblock_read_count to a nonsensical value and Oracle will size it down for you.
     从上面的描述可知,Oracle 9.2之后,有一个名叫SSTIOMAX的东东,限制了MBRC的设置。
     由于SSTIOMAX大多数平台最大单次I/O为1MB,db_block_size为8kb,因此MBRC参数的最大值通常为128。128*8kb=1mb。
     对于设置大于1MB的情形,即MBRC*db_block_size>SSTIOMAX的情形,则设置的值并不生效,而是使用符合SSTIOMAX的最大MBRC值。

3、如何计算MBRC
     The formula as internally used is as below:
         db_file_multiblock_read_count = min(1048576/db_block_size , db_cache_size/(sessions * db_block_size))

       设置DB_FILE_MULTIBLOCK_READ_COUNT以充分利用操作系统I/O缓冲区的大小。应考虑DB_FILE_MULTIBLOCK_READ_COUNT <= 操作系统I/O缓冲区 / Oracle Block的大小,如果DB_FILE_MULTIBLOCK_READ_COUNT设置的太大,会使优化器认为全表扫描更有效而改变执行计划,然后实际情况并非如此。

       如果必须创建小的区间,创建其大小是操作系统I/O缓冲区大小的整数倍

       设置区间尺寸大小的考虑思路应该是合理的利用Oracle的能力以便在全表扫描时执行多块存取,同时读操作又是不能跨区间的。举个例子,假设操作系统I/O缓冲区大小是64KB,考察读取一个640KB大小的表,如果设置为每个区间64KB,一共10个区间,如果执行全表扫描,则Oracle需要10次读操作(相当于一次读一个区间);如果设置为一个640KB的区间,则Oracle还是需要10次读操作(因为操作系统I/O缓冲区大小是64KB),可见压缩区间并不能提高性能;如果设置为每个区间80KB,一共8个区间,则每个区间Oracle需要读两次,第一次读64KB,第二次读这个区间剩余的16KB(读操作不能跨区间),所以总共需要16次读操作(相当于一次读一个区间)。区间尺寸的设置对性能的影响是显而易见的。


案例分析:

案例1

15:21:10 SYS@ test1 >show parameter mult

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

db_file_multiblock_read_count        integer     128


1)查看表中extent分配

14:46:03 SCOTT@ test1 >col segment_name for a20

14:46:15 SCOTT@ test1 >select segment_name,extent_id,bytes,blocks from user_extents

14:46:36   2   where segment_name='T1';

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
SEGMENT_NAME          EXTENT_ID      BYTES     BLOCKS
-------------------- ---------- ---------- ----------
T1                             0       65536           8
T1                             1       65536           8
T1                             2       65536           8
T1                             3       65536           8
T1                             4       65536           8
T1                             5       65536           8
T1                             6       65536           8
T1                             7       65536           8
T1                             8       65536           8
T1                             9       65536           8
T1                            10       65536           8
T1                            11       65536           8
T1                            12       65536           8
T1                            13       65536           8
T1                            14       65536           8
T1                            15       65536           8
T1                            16     1048576         128
SEGMENT_NAME          EXTENT_ID      BYTES     BLOCKS
-------------------- ---------- ---------- ----------
T1                            17     1048576         128
T1                            18     1048576         128
T1                            19     1048576         128
T1                            20     1048576         128
T1                            21     1048576         128
22  rows selected.

2)配置10046进行分析

1
2
3
4
5
6
7
8
9
10
14 : 48 : 00  SCOTT@ test1 >alter session set events  '10046 trace name context forever,level 8' ;
Session altered.
 
14 : 48 : 57  SCOTT@ test1 >select count(*) from t1;
   COUNT(*)
----------
       5002
 
14 : 49 : 09  SCOTT@ test1 >alter session set events  '10046 trace name context off' ;
Session altered.

3)查看trace文件

[oracle@rh6 ~]$ more  /u01/app/oracle/diag/rdbms/test1/test1/trace/test1_ora_4160.trc

1
2
3
4
5
6
7
8
9
10
11
12
13
WAIT # 2 : nam= 'db file sequential read'  ela=  9  file#= 11  block#= 691  blocks= 1  obj#= 16394  tim= 1408604404294713
WAIT # 2 : nam= 'Disk file operations I/O'  ela=  26  FileOperation= 2  fileno= 4  filetype= 2  obj#= 16394  tim= 1408604404294846
WAIT # 2 : nam= 'db file sequential read'  ela=  9  file#= 4  block#= 143  blocks= 1  obj#= 16394  tim= 1408604404294872
WAIT # 2 : nam= 'db file scattered read'  ela=  23  file#= 4  block#= 157  blocks= 3  obj#= 16394  tim= 1408604404294998
WAIT # 2 : nam= 'db file sequential read'  ela=  8  file#= 4  block#= 164  blocks= 1  obj#= 16394  tim= 1408604404295041
WAIT # 2 : nam= 'db file sequential read'  ela=  8  file#= 11  block#= 727  blocks= 1  obj#= 16394  tim= 1408604404295069
WAIT # 2 : nam= 'db file sequential read'  ela=  8  file#= 4  block#= 183  blocks= 1  obj#= 16394  tim= 1408604404295097
WAIT # 2 : nam= 'db file scattered read'  ela=  33  file#= 4  block#= 187  blocks= 5  obj#= 16394  tim= 1408604404295156
WAIT # 2 : nam= 'db file sequential read'  ela=  8  file#= 4  block#= 199  blocks= 1  obj#= 16394  tim= 1408604404295191
WAIT # 2 : nam= 'db file scattered read'  ela=  51  file#= 11  block#= 153  blocks= 8  obj#= 16394  tim= 1408604404295272
WAIT # 2 : nam= 'db file scattered read'  ela=  50  file#= 11  block#= 203  blocks= 8  obj#= 16394  tim= 1408604404295355
WAIT # 2 : nam= 'db file scattered read'  ela=  52  file#= 11  block#= 213  blocks= 8  obj#= 16394  tim= 1408604404295442
......

      从以上文件可以看出,在“db file scattered read”中每次读取的数据块个数(blocks=8)不超过extent中blocks的大小(8个);在“db file sequential read”中每次读取的数据块个数(blocks)为1个。

案例2:

15:21:10 SYS@ test1 >show parameter mult

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

db_file_multiblock_read_count        integer     128


1)创建新的segment

15:08:28 SCOTT@ test1 >create table t2 (id int)

15:08:35   2  storage (initial 2048k next 2048k pctincrease 0);

Table created.

15:08:41 SCOTT@ test1 >col segment_name for a20

15:08:53 SCOTT@ test1 >select segment_name,tablespace_name,extent_id,bytes,blocks from user_extents

15:09:19   2   where segment_name='T2';

1
2
3
4
SEGMENT_NAME         TABLESPACE_NAME                 EXTENT_ID      BYTES     BLOCKS
-------------------- ------------------------------ ---------- ---------- ----------
T2                   USERS                                    0     1048576         128
T2                   USERS                                    1     1048576         128

2)配置10046进行分析

1
2
3
4
5
6
7
8
9
10
15 : 11 : 00  SCOTT@ test1 >alter session set events  '10046 trace name context forever,level 8' ;
Session altered.
 
15 : 14 : 57  SCOTT@ test1 >select count(*) from t2;
   COUNT(*)
----------
       32002
 
15 : 15 : 09  SCOTT@ test1 >alter session set events  '10046 trace name context off' ;
Session altered.

3)查看trace文件

[oracle@rh6 ~]$ more  /u01/app/oracle/diag/rdbms/test1/test1/trace/test1_ora_4260.trc

1
2
3
4
5
PARSE # 5 :c= 0 ,e= 302 ,p= 0 ,cr= 0 ,cu= 0 ,mis= 1 ,r= 0 ,dep= 1 ,og= 1 ,plh= 0 ,tim= 1408605696796384
EXEC # 5 :c= 1000 ,e= 1131 ,p= 0 ,cr= 0 ,cu= 0 ,mis= 1 ,r= 0 ,dep= 1 ,og= 1 ,plh= 3321871023 ,tim= 1408605696797594
WAIT # 5 : nam= 'db file sequential read'  ela=  75  file#= 11  block#= 512  blocks= 1  obj#= 16404  tim= 1408605696797838
WAIT # 5 : nam= 'db file sequential read'  ela=  15  file#= 11  block#= 514  blocks= 1  obj#= 16404  tim= 1408605696797913
WAIT # 5 : nam= 'db file scattered read'  ela=  1123  file#= 11  block#= 528  blocks= 48  obj#= 16404  tim= 1408605696799202

从以上文件可以看出,在“db file scattered read”中每次读取的数据块个数(blocks=48)不超过extent中blocks的大小(128个);在“db file sequential read”中每次读取的数据块个数(blocks)为1个。


附注:

wKiom1P1u0fygRQpAANW1LlFlDY682.jpg

wKiom1P1u0eQx_cAAARtOhrHPd4580.jpg

wKioL1P1vGDAPn7YAAMtnmI0M8I803.jpg










本文转自 客居天涯 51CTO博客,原文链接:http://blog.51cto.com/tiany/1543199,如需转载请自行联系原作者
目录
相关文章
|
7月前
|
JavaScript 前端开发 Java
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——Jsp页面
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——Jsp页面
|
7月前
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——OpSessionview实现
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——OpSessionview实现
|
7月前
|
Java
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——Action的实现类
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——Action的实现类
|
1月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
1月前
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
|
23天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
2月前
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
2月前
|
SQL Oracle 关系型数据库
Oracle SQL:了解执行计划和性能调优
Oracle SQL:了解执行计划和性能调优
76 1

推荐镜像

更多