HelloDBA [English]
搜索Internet 搜索 HelloDBABA
  Oracle技术站。email: fuyuncat@gmail.com  MSN: fuyuncat@hotmail.com   acoug  acoug 

Oracle内存全面分析(3)

[English]

作者: fuyuncat

来源: www.HelloDBA.com

日期: 2008-08-07 14:50:11

分享到  新浪微博 腾讯微博 人人网 i贴吧 开心网 豆瓣 淘宝 推特 Facebook GMail Blogger Orkut Google Bookmarks

1.1.3.3.            Buffer Cache的重要视图

关于Buffer Cacheoracle提供一些重要视图,用于查询关于Buffer Cache的重要信息,为调整Buffer Cache、提高性能提供参考。下面一一介绍它们

·        v$db_cache_advice

上面我们提到了Oracle的建议器,其中有一个针对Buffer Cache的建议器。在我们设置了参数db_cache_adviceTRUE后,经过一段时间的系统运行,Oracle收集到相关统计数据,并根据一定的数学模型,预测出DB_CACHE_SIZE在不同大小情况的性能数据。我们就可以由视图V$DB_CACHE_ADVICE查出这些数据,并根据这些数据调整DB_CACHE_SZIE,使系统性能最优。

下面是关于这个视图的结构描述:

字段

数据类型

描述

ID

NUMBER

缓冲池标识号(从181-6对应于DB_nK_CACHE_SIZEDB_CACHE_SIZE与系统标准块尺寸的序号相关,如DB_BLOCK_SIZE8K,则DB_CACHE_SIZE的标识号为32,4,8…)。7DB_KEEP_CACHE_SIZE8DB_RECYCLE_CACHE_SIZE

NAME

VARCHAR2(20)

缓冲池名称

BLOCK_SIZE

NUMBER

缓冲池块尺寸(字节为单位)

ADVICE_STATUS

VARCHAR2(3)

建议器状态:ON表示建议器在运行;OFF表示建议器已经关闭。当建议器关闭了,视图中的数据是上一次打开所统计得出的。

SIZE_FOR_ESTIMATE

NUMBER

预测性能数据的Cache大小(M为单位)

SIZE_FACTOR

NUMBER

预测的Cache大小因子(即与当前大小的比例)

BUFFERS_FOR_ESTIMATE

NUMBER

预测性能数据的Cache大小(缓冲块数)

ESTD_PHYSICAL_READ_FACTOR

NUMBER

这一缓冲大小时,物理读因子,它是如果缓冲大小为SIZE_FOR_ESTIMATE时,建议器预测物理读数与当前实际物理读数的比率值。如果当前物理读数为0,这个值为空。

ESTD_PHYSICAL_READS

NUMBER

如果缓冲大小为SIZE_FOR_ESTIMATE时,建议器预测物理读数。

 

下面是从这个视图中查询出来的数据:

SQL> select size_for_estimate, estd_physical_read_factor, estd_physical_reads
  2  from v$db_cache_advice
  3  where name = 'DEFAULT';
 
SIZE_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS
----------------- ------------------------- -------------------
               16                    2.0176             6514226
               32                    1.7403             5619048
               48                    1.5232             4917909
               64                    1.3528             4367839
               80                    1.2698             4099816
               96                    1.1933             3852847
              112                    1.1443             3694709
              128                    1.1007             3553685
              144                    1.0694             3452805
              160                    1.0416             3362964
              176                    1.0175             3285085
              192                         1             3228693
              208                    0.9802             3164754
              224                    0.9632             3109920
              240                    0.9395             3033427
              256                    0.8383             2706631
              272                    0.7363             2377209
              288                     0.682             2202116
              304                    0.6714             2167888
              320                    0.6516             2103876
 
20 rows selected

 

当前我们的DB_CACHE_SIZE192M,可以看到,它的物理读因子为1,物理读数为3228693。那么如何根据这些数据调整DB_CACHE_SIZE呢?给出一个方法,找到变化率较平缓的点作为采用值。因为建议器做预测是,DB_CACHE_SIZE的预测值的增长步长是相同的,是16M。我们按照这一步长增加DB_CACHE_SIZE,如果每次增加物理读降低都很明显,就可以继续增加,直到物理读降低不明显,说明继续增加DB_CACHE_SIZE没有太大作用。当然,性能和可用资源是天平的两端,你需要根据自己系统的实际情况调整。

上面的例子中,我们可以考虑将DB_CACHE_SIZE调整到288M。因为在288M之前,物理读因子变化都比较大,而从288M304M以后,这个因子变化趋缓。用一个二维图可以更容易看出这个变化来:

这一视图作为调整DB_CACHE_SIZE以提高性能有很大参考价值。但衡量Buffer Cache是否合适的重要指标还是我们前面提到的缓存命中率(Buffer Hit),而影响缓存命中率往往还有其他因素,如性能极差的SQL语句。

·        V$BUFFER_POOL

这一视图显示了当前实例中所有缓冲池的信息。它的结构如下:

字段

数据类型

描述

ID

NUMBER

缓冲池ID,和上面视图描述相同。

NAME

VARCHAR2(20)

缓冲池名称

BLOCK_SIZE

NUMBER

缓冲池块尺寸(字节为单位)

RESIZE_STATE

VARCHAR2(10)

缓冲池当前状态。

STATIC:没有被正在调整大小

ALLOCATING:正在分配内存给缓冲池(不能被用户取消)

ACTIVATING:正在创建新的缓存块(不能被用户取消)

SHRINKING:正在删除缓存块(能被用户取消)

CURRENT_SIZE

NUMBER

缓冲池大小(M为单位)

BUFFERS

NUMBER

当前缓存块数

TARGET_SIZE

NUMBER

如果正在调整缓冲池大小(即状态不为STATIC),这记录了调整后的大小(M为单位)。如果状态为STATIC,这个值和当前大小值相同。

TARGET_BUFFERS

NUMBER

如果正在调整缓冲池大小(即状态不为STATIC),这记录了调整后的缓存块数。否则,这个值和当前缓存块数相同。

PREV_SIZE

NUMBER

前一次调整的缓冲池大小。如果从来没有调整过,则为0

PREV_BUFFERS

NUMBER

前一次调整的缓存块数。如果从来没有调整过,则为0

LO_BNUM

NUMBER

9i后已经废弃字段

HI_BNUM

NUMBER

9i后已经废弃字段

LO_SETID

NUMBER

9i后已经废弃字段

HI_SETID

NUMBER

9i后已经废弃字段

SET_COUNT

NUMBER

9i后已经废弃字段

·        v$buffer_pool_statistics

V$BUFFER_POOL_STATISTICS视图记录了所有缓冲池的统计数据。它的结构如下:

字段

数据类型

描述

ID

NUMBER

缓冲池ID,和上面视图描述相同。

NAME

VARCHAR2(20)

缓冲池名称

SET_MSIZE

NUMBER

缓冲池中缓存块的最大数

CNUM_REPL

NUMBER

在置换列表中的缓存块数

CNUM_WRITE

NUMBER

在写列表中的缓存块数

CNUM_SET

NUMBER

当前的缓存块数

BUF_GOT

NUMBER

读取过的缓存块数

SUM_WRITE

NUMBER

被写过的缓存块数

SUM_SCAN

NUMBER

被扫描过的缓存块数

FREE_BUFFER_WAIT

NUMBER

等待空闲块统计数

WRITE_COMPLETE_WAIT

NUMBER

等待完成写统计数

BUFFER_BUSY_WAIT

NUMBER

忙(正在被使用)等待统计数

FREE_BUFFER_INSPECTED

NUMBER

确认了的空闲缓存块数(即可用的)

DIRTY_BUFFERS_INSPECTED

NUMBER

确认了的脏缓存块数

DB_BLOCK_CHANGE

NUMBER

被修改过的数据块数

DB_BLOCK_GETS

NUMBER

读取过的数据块数

CONSISTENT_GETS

NUMBER

一致性读统计数

PHYSICAL_READS

NUMBER

物理读统计数

PHYSICAL_WRITES

NUMBER

物理写统计数

查看当前的Buffer Cache命中率:

SQL> select 1-(physical_reads)/(consistent_gets+db_block_gets)
  2  from v$buffer_pool_statistics;
 
1-(PHYSICAL_READS)/(CONSISTENT
------------------------------
             0.967658520581074
 
SQL>
·        v$bh

这一视图在深入定位缓冲区问题时很有用。它记录了缓冲区中所有数据块对象。粒度非常细。这个视图最初的目的是用于OPSOracle Parallel Server Oracle平行服务器,9i后称为RAC)的,是用于保证RAC中各个节点的数据一致性的。但是,我们可以通过它来查询Buffer Cache的使用情况,找出大量消耗Buffer Cache的对象。下面的语句就可以完成这一工作:

SQL> column c0 heading 'Owner'                     format a15
SQL> column c1 heading 'Object|Name'               format a30
SQL> column c2 heading 'Number|of|Buffers'         format 999,999
SQL> column c3 heading 'Percentage|ofData|Buffer' format 999,999,999
SQL> select
  2     owner                        c0,
  3     object_name                  c1,
  4     count(1)                     c2,
  5     (count(1)/(select count(*) from v$bh)) *100  c3
  6  from
  7     dba_objects o,
  8     v$bh        bh
  9  where
 10     o.object_id  = bh.objd
 11  and
 12     o.owner not in ('SYS','SYSTEM')
 13  group by
 14     owner,
 15     object_name
 16  order by
 17     count(1) desc
 18  ;
 
C0              C1                                     C2         C3
--------------- ------------------------------ ---------- ----------
PLSQLDEV        STANDARD_CITY                  17290      72.5860621
DBOWNER         MSG_LOG                        2          0.00839630
DBOWNER         COUNTRY_PK                     1          0.00419815
DBOWNER         PARAMETER                      1          0.00419815
DBOWNER         PARAMETER_PK                   1          0.00419815
DBOWNER         MSG_LOG_IDX1                   1          0.00419815
 
6 rows selected
 
SQL>

 

更重要的是,这个视图记录的粒度非常细,一条记录对应了一个数据块。这对于我们做内存问题分析或分析Oracle行为时很有帮助。

下面是这个视图的结构:

字段

数据类型

说明

FILE#

NUMBER

缓存块对应的数据块所在的数据文件号。可以通过视图DBA_DATA_FILESV$DBFILES查询

BLOCK#

NUMBER

缓存块对应的数据块编号

CLASS#

NUMBER

分类编号

STATUS

VARCHAR2(1)

缓存块的状态

FREE:空闲,没有被使用

XCUR:排斥(正在被使用)

SCUR:可被共享

CR:一致性读

READ:正在从磁盘读入

MREC:处于从存储介质恢复状态

IREC:处于实例恢复状态

XNC

NUMBER

缓存块上由于和其他实例争用导致的PCMParallel Cache Management并行缓存管理)x to null锁的数量。这一字段已经被废弃。

LOCK_ELEMENT_ADDR

RAW(4 | 8)

缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同,说明他们被同一锁锁住。

LOCK_ELEMENT_NAME

NUMBER

缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同,说明他们被同一锁锁住。

LOCK_ELEMENT_CLASS

NUMBER

缓存块上PCM锁的地址。如果多个缓存块的PCM锁地址相同,说明他们被同一锁锁住。

FORCED_READS

NUMBER

由于其他实例的PCM锁锁住了该缓存块,导致当前实例尝试重新请求读该缓冲块的次数。

FORCED_WRITES

NUMBER

由于其他实例的PCM锁锁住了该缓存块,导致当前实例尝试重新请求写该缓冲块的次数。

DIRTY

VARCHAR2(1)

脏标志:Y – 块被修改过,是脏块;N – 不是脏块

TEMP

VARCHAR2(1)

是否为临时块:Y – 是;N – 否。

PING

VARCHAR2(1)

是否被ping住:Y – 是;N – 否。

STALE

VARCHAR2(1)

是否是陈旧块:Y – 是;N – 否。

DIRECT

VARCHAR2(1)

是否为直接读写块:Y – 是;N – 否。

NEW

VARCHAR2(1)

字段被废弃,始终为N

OBJD

NUMBER

数据块所属对象的对象标号,可以查询dba_objects

TS#

NUMBER

数据块所在的表空间号,可以查询v$tablespaces

1.1.4.   共享池(Shared pool

SGA中的共享池由库缓存(Library Cache)、字典缓存(Dictionary Cache)、用于并行执行消息的缓冲以及控制结构组成。

Shared Pool的大小由参数SHARED_POOL_SIZE决定。在32位系统中,这个参数的默认值是8M,而64位系统中的默认值位64M。最大为4G

对于Shared Pool的内存管理,是通过修正过的LRU算法表来实现的。

下面分别介绍Shared Pool的几个组成部分。

1.1.4.1.            库缓存(Library Cache

Library Cache中包括共享SQL区(Shared SQL Areas)、PL/SQL存储过程和包以及控制结构(如锁、库缓存句柄)。

任何用户都可以访问共享SQL区(可以通过v$sqlarea访问,随后会介绍这个重要视图)。因此库缓存存在于SGA的共享池中。

·        共享SQL区和私有SQL

Oracle会为每一条SQL语句运行(每运行一条语句Oracle都会打开一个游标)提供一个共享SQL区(Shared SQL Areas)和私有SQL区(Private SQL Areas属于PGA)。当发现两个(或多个)用户都在运行同一SQL语句时,Oracle会重新组织SQL区,使这些用户能重用共享SQL区。但他们还会在私有SQL区中保存一份这条SQL语句的拷贝。

一个共享SQL区中保存了一条语句的解析树和查询计划。在多用户系统中,Oracle通过为SQL语句使用同一共享SQL区多次运行来节省内存。

当一条新的SQL语句被解析时,Oracle从共享池中分配一块内存来存储共享SQL区。这块内存的大小与这条语句的复杂性相关。如果Shared Pool不够空间分配给共享SQL区,Oracle将释放从LRU链表中查找到最近最少使用的内存块,直到有足够空间给新的语句的共享SQL区。如果Oracle释放的是一个共享SQL区的内存,那么相应的语句在下次执行时需要再次解析并重新分配共享SQL区。而从解析语句到分配共享SQL区是一个比较消耗CPU的工程。这就是为什么我们提倡使用绑定变量的原因了。在没有使用绑定变量时,语句中的变量的数值不同,oracle就视为一条新的语句(9i后可以通过cursor_sharing来控制),重复上面的解析、内存分配的动作,将大大消耗系统资源,降低系统性能。

·        PL/SQL程序单元

Oracle对于PL/SQL程序单元(存储过程、函数、包、匿名PL/SQL块和触发器)的处理过程和对单个的SQL语句的处理过程相似。它会分配一个共享区来存储被解析、编译过的程序单元。同时分配一个私有区域来存放运行程序单元的会话所指定的程序单元的参数值(包括本地变量、全局变量和包变量——这也叫做包的实例化)和用于执行程序所需的内存。如果多个用户运行同一个程序单元,则他们共享同一个共享区域,并且各自保持一份私有区域,用于用户会话中指定的变量值。

而一个PL/SQL程序单元中的每条单个SQL语句的处理过程则和上面描述的SQL语句的处理过程相同。要注意一点,尽管这些语句是从PL/SQL程序单元中来的,但是Oracle还是会为这些语句分配一块共享SQL区,同时为每个用户分配一个相应的私有SQL区。

 

Top

Copyright ©2005,HelloDBA.Com 保留一切权利

申明
by fuyuncat