详细解读 STATSPACK 报告4

、闩锁统计信息

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

、共享池统计信息

/* 字典缓存统计

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

、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

……省略部分内容……

、资源限制统计信息

这部分是关于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

、初始化统计信息

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

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博客

详细解读 STATSPACK 报告4（Latch）

最新文章