详细解读 STATSPACK 报告4(Latch)

详细解读 STATSPACK 报告4

16 、闩锁统计信息

Latch是一种低级排队机制,用于防止对内存结构的并行访问,保护系统全局区(SGA)共享内存结构。Latch是一种快速地被获取和释放的内存锁。如果latch不可用,就会记录latch free miss 。

有两种类型的Latch:willing to wait和(immediate)not willing to wait。

对于愿意等待类型(willing-to-wait)的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch, 然后该进程转入睡眠状态,百分之一秒之后醒来,按顺序重复以前的步骤。在8i/9i中默认值是_spin_count=2000。睡眠的时间会越来越长。

  对于不愿意等待类型(not-willing-to-wait)的latch,如果该闩不能立即得到的话,那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。

  大多数Latch问题都可以归结为以下几种:

  没有很好的是用绑定变量(library cache latch和shared pool cache)、重作生成问题(redo allocation latch)、缓冲存储竞争问题(cache buffers LRU chain),以及buffer cache中的存在"热点"块(cache buffers chain)。

另外也有一些latch等待与bug有关,应当关注Metalink相关bug的公布及补丁的发布。

当latch miss ratios大于0.5%时,就需要检查latch的等待问题。

如果SQL语句不能调整,在8.1.6版本以上,可以通过设置CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数可能会带来一定的副作用,可能会导致执行计划不优,另外对于Java的程序,有相关的bug,具体应用应该关注Metalink的bug公告。

下面对几个重要类型的latch等待加以说明:

1)        latch free:当‘latch free’在报告的高等待事件中出现时,就表示可能出现了性能问题,就需要在这一部分详细分析出现等待的具体的latch的类型,然后再调整。

2)        cache buffers chain:cbc latch表明热块。为什么这会表示存在热块?为了理解这个问题,先要理解cbc的作用。ORACLE对buffer cache管理是以hash链表的方式来实现的(oracle称为buckets,buckets的数量由_db_block_hash_buckets定义)。cbc latch就是为了保护buffer cache而设置的。当有并发的访问需求时,cbc会将这些访问串行化,当我们获得cbc latch的控制权时,就可以开始访问数据,如果我们所请求的数据正好的某个buckets中,那就直接从内存中读取数据,完成之后释放cbc latch,cbc latch就可以被其他的用户获取了。cbc latch获取和释放是非常快速的,所以这种情况下就一般不会存在等待。但是如果我们请求的数据在内存中不存在,就需要到物理磁盘上读取数据,这相对于latch来说就是一个相当长的时间了,当找到对应的数据块时,如果有其他用户正在访问这个数据块,并且数据块上也没有空闲的ITL槽来接收本次请求,就必须等待。在这过程中,我们因为没有得到请求的数据,就一直占有cbc latch,其他的用户也就无法获取cbc latch,所以就出现了cbc latch等待的情况。所以这种等待归根结底就是由于数据块比较hot的造成的。

解决方法可以参考前面在等待事件中的3) buffer busy wait中关于热块的解决方法。

3)        cache buffers lru chain:该latch用于扫描buffer的LRU链表。三种情况可导致争用:1)buffer cache太小 ;2)buffer cache的过度使用,或者太多的基于cache的排序操作;3)DBWR不及时。解决方法:查找逻辑读过高的statement,增大buffer cache。

4)        Library cache and shared pool 争用:

library cache是一个hash table,我们需要通过一个hash buckets数组来访问(类似buffer cache)。library cache latch就是将对library cache的访问串行化。当有一个sql(或者PL/SQL procedure,package,function,trigger)需要执行的时候,首先需要获取一个latch,然后library cache latch就会去查询library cache以重用这些语句。在8i中,library cache latch只有一个。在9i中,有7个child latch,这个数量可以通过参数_KGL_LATCH_ COUNT修改(最大可以达到66个)。当共享池太小或者语句的reuse低的时候,会出现‘shared pool’、‘library cache pin’或者 ‘library cache’ latch的争用。解决的方法是:增大共享池或者设置CURSOR_SHARING=FORCE|SIMILAR ,当然我们也需要tuning SQL statement。为减少争用,我们也可以把一些比较大的SQL或者过程利用DBMS_SHARED_POOL.KEEP包来pinning在shared pool中。

shared pool内存结构与buffer cache类似,也采用的是hash方式来管理的。共享池有一个固定数量的hash buckets,通过固定数量的library cache latch来串行化保护这段内存的使用。在数据启动的时候,会分配509个hash buctets,2*CPU_COUNT个library cache latch。当在数据库的使用中,共享池中的对象越来越多,oracle就会以以下的递增方式增加hash buckets的数量:509,1021,4093,8191,32749,65521,131071,4292967293。我们可以通过设置下面的参数来实现_KGL_BUCKET_COUNT,参数的默认值是0,代表数量509,最大我们可以设置为8,代表数量131071。

我们可以通过x$ksmsp来查看具体的共享池内存段情况,主要关注下面几个字段:

KSMCHCOM—表示内存段的类型

ksmchptr—表示内存段的物理地址

ksmchsiz—表示内存段的大小

ksmchcls—表示内存段的分类。recr表示a recreatable piece currently in use that can be a candidate for flushing when the shared pool is low in available memory; freeabl表示当前正在使用的,能够被释放的段; free表示空闲的未分配的段; perm表示不能被释放永久分配段。

降低共享池的latch 争用,我们主要可以考虑如下的几个事件:

1、使用绑定变量

2、使用cursor sharing

3、设置session_cached_cursors参数。该参数的作用是将cursor从shared pool转移到pga中。减小对共享池的争用。一般初始的值可以设置为100,然后视情况再作调整。

4、设置合适大小的共享池

5)        Redo Copy:这个latch用来从PGA中copy redo records到redo log buffer。latch的初始数量是2*COU_OUNT,可以通过设置参数_LOG_SIMULTANEOUS_COPIES在增加latch的数量,减小争用。

6)        Redo allocation:该latch用于redo log buffer的分配。减小这种类型的争用的方法有3个:

增大redo log buffer

适当使用nologging选项

避免不必要的commit操作

7)        Row cache objects:该latch出现争用,通常表明数据字典存在争用的情况,这往往也预示着过多的依赖于公共同义词的parse。解决方法:1)增大shared pool  2)使用本地管理的表空间,尤其对于索引表空间

Latch事件

建议解决方法

Library cache

使用绑定变量; 调整shared_pool_size.

Shared pool

使用绑定变量; 调整shared_pool_size.

Redo allocation

减小 redo 的产生; 避免不必要的commits.

Redo copy

增加 _log_simultaneous_copies. 

Row cache objects

增加shared_pool_size

Cache buffers chain

增大 _DB_BLOCK_HASH_BUCKETS ; make it prime.  

Cache buffers LRU chain

使用多个缓冲池;调整引起大量逻辑读的查询

注:在这里,提到了不少隐藏参数,也有利用隐藏参数来解决latch的方法描述,但是在实际的操作中,强烈建议尽量不要去更改隐藏参数的默认值。

Latch Activity for DB: ORA92  Instance: ora92  Snaps: 13 -14

->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for

  willing-to-wait latch get requests

->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests

->"Pct Misses" for both should be very close to 0.0

                                          Pct    Avg   Wait                 Pct

                             Get          Get   Slps   Time       NoWait NoWait

Latch                      Requests      Miss  /Miss    (s)     Requests   Miss

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

Consistent RBA                   67,061    0.0             0            0

FIB s.o chain latch                   4    0.0             0            0

FOB s.o list latch                  240    0.0             0            0

SQL memory manager latch              1    0.0             0          281    0.0

SQL memory manager worka        296,916    0.0    0.0      0            0

active checkpoint queue           1,340    0.0             0            0

cache buffer handles              2,980    0.0    0.0      0            0

cache buffers chains         44,382,255    5.4    0.0      0       93,328    0.0

cache buffers lru chain         148,064    0.0    0.0      0      131,731    0.0

channel handle pool latc             30    0.0             0            0

channel operations paren            627    0.0             0            0

checkpoint queue latch          463,732    0.0    0.0      0       85,528    0.0

child cursor hash table          36,633    0.0             0            0

dml lock allocation             450,770    1.0    0.0      0            0

dummy allocation                  1,434    1.1    0.0      0            0

enqueue hash chains             638,884    0.3    0.0      0            0

enqueues                        233,476    0.2    0.0      0            0

event group latch                    14    0.0             0            0

global tx hash mapping              264    0.0             0            0

hash table column usage               5    0.0             0           14    0.0

job workq parent latch                0     0     1,191   8.6

job_queue_processes para            182    0.0             0            0

ktm global data                       3    0.0             0            0

kwqit: protect wakeup ti             27    0.0             0            0

lgwr LWN SCN                     67,123    0.0    0.0      0            0

library cache                 4,755,237    1.1    0.0      0            0

library cache load lock             274    0.0             0            0

library cache pin             3,867,684    0.2    0.0      0            0

library cache pin alloca        470,588    0.3    0.0      0            0

list of block allocation         19,378    0.0             0            0

loader state object free             84    0.0             0            0

longop free list parent               1    0.0             0            0

messages                        212,197    0.1    0.0      0            0

mostly latch-free SCN            67,390    0.0    0.0      0            0

multiblock read objects           4,601    0.0             0            0

ncodef allocation latch              14    0.0             0            0

object stats modificatio             25    0.0             0            0

post/wait queue                128,656    0.0    0.0      0       74,194    0.2

process allocation                  14    0.0             0           14    0.0

process group creation               30    0.0             0            0

redo allocation               1,477,895    0.2    0.0      0            0

redo copy                        0           0    1,344,659    0.1

redo writing                    203,129    0.0    0.0      0            0

row cache enqueue latch          21,995    0.1    0.0      0            0

row cache objects                30,913    1.9    0.0      0            0

sequence cache                  122,787    0.3    0.0      0            0

session allocation              499,051    0.4    0.0      0            0

session idle bit                901,267    0.0    0.0      0            0

session switching                    14    0.0             0            0

session timer                       291    0.0             0            0

Latch Activity for DB: ORA92  Instance: ora92  Snaps: 13 -14

->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for

  willing-to-wait latch get requests

->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests

->"Pct Misses" for both should be very close to 0.0

                                          Pct    Avg   Wait                 Pct

                              Get          Get   Slps   Time       NoWait NoWait

Latch                       Requests      Miss  /Miss    (s)     Requests   Miss

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

shared pool                  2,819,295    0.1    0.0      0            0

sim partition latch                   0                    0          252    0.0

simulator hash latch         1,046,772    0.0    0.0      0            0

simulator lru latch                596    0.0             0       15,390    5.7

sort extent pool                    17    0.0             0            0

spilled msgs queues list            27    0.0             0            0

transaction allocation           3,207    0.4    0.0      0            0

transaction branch alloc            62    0.0             0            0

undo global data               286,249    0.1    0.0      0            0

user lock                        1,432    0.6    0.0      0            0

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

Latch Sleep breakdown for DB: ORA92  Instance: ora92  Snaps: 13 -14

-> ordered by misses desc

                                      Get                            Spin &

Latch Name                       Requests      Misses      Sleeps Sleeps 1->4

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

cache buffers chains           44,382,255   2,408,704       1,302 0/0/0/0/0

library cache                   4,755,237      51,183           5 51178/5/0/0/

                                                                  0

session allocation                499,051       2,050           1 2049/1/0/0/0

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

Latch Miss Sources for DB: ORA92  Instance: ora92  Snaps: 13 -14

-> only latches with sleeps are shown

-> ordered by name, sleeps desc

                                                     NoWait              Waiter

Latch Name               Where                       Misses     Sleeps   Sleeps

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

cache buffers chains     kcbgtcr: kslbegin excl           0        859      741

cache buffers chains     kcbchg: kslbegin: bufs not       0        217      139

cache buffers chains     kcbgcur: kslbegin                0        135      130

cache buffers chains     kcbrls: kslbegin                 0         58      188

cache buffers chains     kcbgtcr: fast path               0         11        3

cache buffers chains     kcbbic2                          0          3        0

cache buffers chains     kcbnlc                           0          3        3

cache buffers chains     kcbget: pin buffer               0          3        1

cache buffers chains     kcbget: exchange rls             0          3        2

cache buffers chains     kcbchg: kslbegin: call CR        0          3       70

cache buffers chains     kcbzwb                           0          1        0

library cache            kglpnc: child                    0          3        2

library cache            kglic                            0          1        0

library cache            kglupc: child                    0          1        0

session allocation       ksuxds: not user session         0          1        0

 

17、共享池统计信息

/* 字典缓存统计

Dictionary Cache Stats for DB: ORA92  Instance: ora92  Snaps: 13 -14

->"Pct Misses"  should be very low (< 2% in most cases)

->"Cache Usage" is the number of cache entries being used

->"Pct SGA"     is the ratio of usage to allocated size for that cache

 

                                   Get    Pct    Scan   Pct      Mod      Final

Cache                         Requests   Miss    Reqs  Miss     Reqs      Usage

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

dc_database_links                  528    0.0       0              0          2

dc_histogram_defs                   22   86.4       0              0      4,295

dc_object_ids                       69   29.0       0              0        403

dc_objects                         233   36.1       0              0        895

dc_profiles                        705    0.0       0              0          1

dc_rollback_segments             3,911    0.0       0              0        233

dc_segments                        187    1.1       0             12      5,778

dc_sequences                     1,978    0.0       0          1,978          9

dc_tablespace_quotas                12    0.0       0             12          4

dc_tablespaces                     458    0.0       0              0         11

dc_user_grants                     120    0.0       0              0         18

dc_usernames                        56    0.0       0              0         12

dc_users                         3,674    0.0       0              0         20

 

/* 库缓存详细信息,。

Get Requests:get表示一种类型的锁,语法分析锁。这种类型的锁在引用了一个对象的那条SQL语句的语法分析阶段被设置在该对象上。每当一条语句被语法分析一次时 ,Get Requests的值就增加1。

pin requests:pin也表示一种类型的锁,是在执行发生的加锁。每当一条语句执行一次,pin requests的值就增加1。

reloads:reloads列显示一条已执行过的语句因Library Cache使该语句的已语法分析版本过期或作废而需要被重新语法分析的次数。

invalidations:失效发生在一条已告诉缓存的SQL语句即使已经在library cache中,但已被标记为无效并迎词而被迫重新做语法分析的时候。每当已告诉缓存的语句所引用的对象以某种方式被修改时,这些语句就被标记为无效。

pct miss应该不高于1%。

Reloads /pin requests <1%,否则应该考虑增大SHARED_POOL_SIZE。

该部分信息通过v$librarycache视图统计得到:

select namespace,gethitratio,pinhitratio,reloads,invalidations

from v$librarycache

where namespace in ('SQL AREA','TABLE/PROCEDURE','BODY','TRIGGER', 'INDEX');

 

Library Cache Activity for DB: ORA92  Instance: ora92  Snaps: 13 -14

->"Pct Misses"  should be very low

 

                         Get  Pct        Pin        Pct               Invali-

Namespace           Requests  Miss     Requests     Miss     Reloads  dations

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

BODY                   1,699    0.0          1,699    0.0          0        0

INDEX                     54    0.0             54    0.0          0        0

SQL AREA               5,665    0.0      1,497,193    0.4      6,086        0

TABLE/PROCEDURE       92,424    0.1        429,557    0.1          0        0

TRIGGER                1,412    0.0          1,412    0.0          0        0

 

/* 共享池调整建议。

Shared Pool Advisory for DB: ORA92  Instance: ora92  End Snap: 14

-> Note there is often a 1:Many correlation between a single logical object

   in the Library Cache, and the physical number of memory objects associated

   with it.  Therefore comparing the number of Lib Cache objects (e.g. in

   v$librarycache), with the number of Lib Cache Memory Objects is invalid

                                                          Estd

Shared Pool    SP       Estd         Estd     Estd Lib LC Time

   Size for  Size  Lib Cache    Lib Cache   Cache Time   Saved  Estd Lib Cache

  Estim (M) Factr   Size (M)      Mem Obj    Saved (s)   Factr    Mem Obj Hits

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

        224    .5         97       55,129   10,514,328     1.0     807,719,425

        272    .7        112       68,387   10,514,329     1.0     807,719,480

        320    .8        113       68,787   10,514,329     1.0     807,719,485

        368    .9        113       68,787   10,514,329     1.0     807,719,485

        416   1.0        113       68,787   10,514,329     1.0     807,719,485

        464   1.1        113       68,787   10,514,329     1.0     807,719,485

        512   1.2        113       68,787   10,514,329     1.0     807,719,485

        560   1.3        113       68,787   10,514,329     1.0     807,719,485

        608   1.5        113       68,787   10,514,329     1.0     807,719,485

        656   1.6        113       68,787   10,514,329     1.0     807,719,485

        704   1.7        113       68,787   10,514,329     1.0     807,719,485

        752   1.8        113       68,787   10,514,329     1.0     807,719,485

        800   1.9        113       68,787   10,514,329     1.0     807,719,485

        848   2.0        113       68,787   10,514,329     1.0     807,719,485

 

18、SGA内存分配

这部分是关于SGA内存分配的一个描述,我们可以通过show sga等命令也可以查看到这里的内容。

Fixed Size:

    oracle 的不同平台和不同版本下可能不一样,但对于确定环境是一个固定的值,里面存储了SGA 各部分组件的信息,可以看作引导建立SGA的区域。

Variable Size:

    包含了shared_pool_size、java_pool_size、large_pool_size 等内存设置。

Database Buffers:

    指数据缓冲区,在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle 三部分内存。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、 db_nk_cache_size。

Redo Buffers:

    指日志缓冲区,log_buffer。对于logbuffer,我们会发现在v$parameter、v$sgastat、v$sga的值不一样。v$parameter是我们可以自己设定的值,也可以设定为0,这时候,oracle降会以默认的最小值来设置v$sgastat的值,同时v$sga也是最小的值。v$sgastat的值是基于参数log_buffer的设定值,再根据一定的计算公式得到的一个值。v$sga的值,则是根据v$sgastat的值,然后选择再加上8k-11k的一个值,得到min(n*4k)的一个值。就是说得到的结果是4k的整数倍,也就是说v$sga是以4k的单位递增的。

SGA Memory Summary for DB: ORA92  Instance: ora92  Snaps: 13 -14

SGA regions                       Size in Bytes

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

Database Buffers                  5,368,709,120

Fixed Size                              754,760

Redo Buffers                          2,371,584

Variable Size                     3,137,339,392

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

sum                               8,509,174,856

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

SGA breakdown difference for DB: ORA92  Instance: ora92  Snaps: 13 -14

Pool   Name                                Begin value        End value  % Diff

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

java   free memory                          33,554,432       33,554,432    0.00

large  free memory                          16,777,216       16,777,216    0.00

shared 1M buffer                             1,056,768        1,056,768    0.00

……省略部分内容……

 

19、资源限制统计信息

这部分是关于oracle资源限制的一个描述。只显示当前正在使用或者最大使用率超过80%的资源限制。

Resource Limit Stats for DB: ORA92  Instance: ora92  End Snap: 14

-> only rows with Current or Maximum Utilization > 80% of Limit are shown

-> ordered by resource name

 

                                 Current      Maximum     Initial

Resource Name                  Utilization  Utilization  Allocation      Limit

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

parallel_max_servers                      0            5          6          6

 

 

20、初始化统计信息

这是报表的最后一部分,是关于常用重要的一些系统的初始化参数设置的汇总情况。不再详述。

init.ora Parameters for DB: ORA92  Instance: ora92  Snaps: 13 -14

                                                                  End value

Parameter Name                Begin value                       (if different)

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

aq_tm_processes               1

background_dump_dest          /opt/oracle/app/oracle/admin/ora9

compatible                    9.2.0.0.0

control_files                 /dev/rlv_ctrl1, /dev/rlv_ctrl2, /

core_dump_dest                /opt/oracle/app/oracle/admin/ora9

cursor_sharing                SIMILAR

db_block_size                 8192

db_cache_size                 5368709120

db_domain

db_file_multiblock_read_count 8

db_name                       ora92

……省略部分内容……

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

End of Report

----END----

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22782597/viewspace-619429/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/22782597/viewspace-619429/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值