8-2 Enqueue Activity
enqueue 队列锁等待
Enqueue Activity Snaps: 70719-70723 -> only enqueues with waits are shown -> Enqueue stats gathered prior to 10g should not be compared with 10g data -> ordered by Wait Time desc, Waits desc Enqueue Type (Request Reason) ------------------------------------------------------------------------------ Requests Succ Gets Failed Gets Waits Wt Time (s) Av Wt Time(ms) ------------ ------------ ----------- ----------- ------------ -------------- TX-Transaction (index contention) 201,270 201,326 0 193,948 97,517 502.80 TM-DML 702,731 702,681 4 1,081 46,671 43,174.08 SQ-Sequence Cache 28,643 28,632 0 17,418 35,606 2,044.19 HW-Segment High Water Mark 9,210 8,845 376 1,216 12,505 10,283.85 TX-Transaction (row lock contention) 9,288 9,280 0 9,232 10,486 1,135.80 CF-Controlfile Transaction 15,851 14,094 1,756 2,798 4,565 1,631.64 TX-Transaction (allocate ITL entry) 471 369 102 360 169 469.28
Enqueue Type (Request Reason) enqueue 队列的类型，大家在研究 enqueue 问题前 至少搞清楚enqueue type 和enqueue mode ， enqueue type是队列锁所要保护的资源 如 TM 表锁 CF 控制文件锁， enqueue mode 是持有队列锁的模式 (SS、SX 、S、SSX、X)
Requests : 申请对应的enqueue type资源或者队列转换(enqueue conversion 例如 S 转 SSX ) 的次数
Succ Gets ：对应的enqueue被成功 申请或转换的次数
Failed Gets ：对应的enqueue的申请 或者转换失败的次数
Waits ：由对应的enqueue的申请或者转换而造成等待的次数
Wt Time (s) ： 由对应的enqueue的申请或者转换而造成等待的等待时间
Av Wt Time(ms) ：由对应的enqueue的申请或者转换而造成等待的平均等待时间 ， Wt Time (s) / Waits ,单位为ms
主要的enqueue 等待事件：
enq: TX – row lock/index contention、allocate ITL等待事件
Oracle队列锁enq:TS,Temporary Segment (also TableSpace)
9-1 Undo Segment Summary
Undo Segment Summary Snaps: 70719-70723 -> Min/Max TR (mins) - Min and Max Tuned Retention (minutes) -> STO - Snapshot Too Old count, OOS - Out of Space count -> Undo segment block stats: -> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed -> eS - expired Stolen, eR - expired Released, eU - expired reUsed Undo Num Undo Number of Max Qry Max Tx Min/Max STO/ uS/uR/uU/ TS# Blocks (K) Transactions Len (s) Concurcy TR (mins) OOS eS/eR/eU ---- ---------- --------------- -------- -------- --------- ----- -------------- 4 85.0 200,127 55,448 317 1040.2/10 0/0 0/0/0/0/0/0 ------------------------------------------------------------- Undo Segment Stats Snaps: 70719-70723 -> Most recent 35 Undostat rows, ordered by Time desc Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/uU/ End Time Blocks Transactions Len (s) Concy (mins) OOS eS/eR/eU ------------ ----------- ------------ ------- ------- ------- ----- ------------ 29-Aug 05:52 11,700 35,098 55,448 234 1,070 0/0 0/0/0/0/0/0 29-Aug 05:42 12,203 24,677 54,844 284 1,065 0/0 0/0/0/0/0/0 29-Aug 05:32 14,132 37,826 54,241 237 1,060 0/0 0/0/0/0/0/0 29-Aug 05:22 14,379 32,315 53,637 317 1,050 0/0 0/0/0/0/0/0 29-Aug 05:12 15,693 34,157 53,033 299 1,045 0/0 0/0/0/0/0/0 29-Aug 05:02 16,878 36,054 52,428 250 1,040 0/0 0/0/0/0/0/0
数据来源： WRH$_UNDOSTAT ， undo相关的使用信息每10分钟刷新到v$undostat中
Undo Extent有三种状态 active 、unexpired 、expired
active => extent中 包括了活动的事务 ，active的undo extent 一般不允许被其他事务重用覆盖
unexpired => extent中没有活动的事务，但相关undo 记录从inactive到目前还未经过undo retention(注意 auto undo retention的问题 因为这个特性 可能在观察dba_undo_extents时看到大部分block都是unexpired，这是正常的) 指定的时间，所以为unexpired。 对于没有guarantee retention的undo tablespace而言，unexpired extent可能被 steal 为其他事物重用
expired => extent中没有活动事务，且超过了undo retention的时间
Undo TS# 在使用的这个undo 表空间的表空间号， 一个实例 同一时间只能用1个undo tablespace ， RAC不同节点可以用不同的undo tablespace
Num Undo Blocks (K) 指被消费的 undo 数据块的数量, (K)代表要乘以1000才是实际值； 可以用该指标来评估系统对undo block的消费量， 以便基于实际负载情况来评估UNDO表空间的大小
Number of Transactions 指该段时间内该undo表空间上执行过的事务transaction总量
Max Qry Len (s) 该时段内 持续最久的查询 时间， 单位为秒
Max Tx Concy 该时段内 最大的事务并发量
Min/Max TR (mins) 最小和最大的tuned undo retention ，单位为分钟； tuned undo retention 是自动undo调优特性，见undo自动调优介绍。
STO/ OOS STO 指 ORA-01555 Snapshot Too Old错误出现的次数； OOS – 指Out of Space count 错误出现的次数
uS – unexpired Stolen 尝试从未过期的undo extent中偷取undo space的次数
uR – unexpired Released 从未过期的undo extent中释放的块数目
uU – unexpired reUsed 未过期的undo extent中的block被其他事务重用的 块数目
eS – expired Stolen 尝试从过期的undo extent中偷取undo space的次数
eR – expired Released 从过期的undo extent中释放的块数目
eU – expired reUsed 过期的undo extent中的block被其他事务重用的 块数目
| UNXPSTEALCNT | NUMBER | Number of attempts to obtain undo space by stealing unexpired extents from other transactions |
| UNXPBLKRELCNT | NUMBER | Number of unexpired blocks removed from certain undo segments so they can be used by other transactions |
| UNXPBLKREUCNT | NUMBER | Number of unexpired undo blocks reused by transactions |
| EXPSTEALCNT | NUMBER | Number of attempts to steal expired undo blocks from other undo segments |
| EXPBLKRELCNT | NUMBER | Number of expired undo blocks stolen from other undo segments |
| EXPBLKREUCNT | NUMBER | Number of expired undo blocks reused within the same undo segments |
| SSOLDERRCNT | NUMBER | Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error. |
10-1 Latch Activity
Latch Activity Snaps: 70719-70723 -> "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 Name Requests Miss /Miss (s) Requests Miss ------------------------ -------------- ------ ------ ------ ------------ ------ AQ deq hash table latch 4 0.0 0 0 N/A ASM Keyed state latch 9,048 0.1 0.2 0 0 N/A ASM allocation 15,017 0.2 0.8 1 0 N/A ASM db client latch 72,745 0.0 0 0 N/A ASM map headers 5,860 0.6 0.6 1 0 N/A ASM map load waiting lis 1,462 0.0 0 0 N/A ASM map operation freeli 63,539 0.1 0.4 1 0 N/A ASM map operation hash t 76,484,447 0.1 1.0 66 0 N/A
latch name Latch闩的名字
Get Requests latch被以willing-to-wait模式申请并获得的次数
Pct Get Miss miss是指latch被以willing-to-wait 模式申请但是申请者必须等待的次数， Pct Get Miss = Miss/Get Requests ; miss可以从后面的Latch Sleep Breakdown 获得
Avg Slps /Miss Sleep 是指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数 ； Avg Slps /Miss = Sleeps/ Misses ; Sleeps可以从后面的Latch Sleep Breakdown 获得
Wait Time (s) 指花费在等待latch上的时间，单位为秒
NoWait Requests 指latch被以no-wait模式来申请的次数
Pct NoWait Miss 以no-wait模式来申请latch但直接失败的次数
对于高并发的latch例如cache buffers chains，其Pct Misses应当十分接近于0
一般的调优原则：
如果latch : cache buffers chains是 Top 5 事件，则需要考虑优化SQL减少 全表扫描 并减少Top buffer gets SQL语句的逻辑读
如果latch : redo copy 、redo allocation 等待较多，则可以考虑增大LOG_BUFFER
如果latch:library cache 发生较多，则考虑增大shared_pool_size
10-2 Latch Sleep Breakdown
Latch Sleep Breakdown DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723 -> ordered by misses desc Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- cache buffers chains 3,365,097,866 12,831,875 130,058 12,683,450 row cache objects 69,050,058 349,839 1,320 348,649 session idle bit 389,437,460 268,285 2,768 265,752 enqueue hash chains 8,698,453 239,880 22,476 219,950 ges resource hash list 8,388,730 158,894 70,728 91,104 gc element 100,383,385 135,759 6,285 129,742 gcs remastering latch 12,213,169 72,373 1 72,371 enqueues 4,662,545 46,374 259 46,155 ASM map operation hash tab 76,484,447 46,231 45,210 1,952 Lsod array latch 72,598 24,224 24,577 1,519
latch name Latch闩的名字
Get Requests latch被以willing-to-wait模式申请并获得的次数
misses 是指latch被以willing-to-wait 模式申请但是申请者必须等待的次数
9i以后miss之后一般有2种情况 spin gets了 或者sleep一睡不醒直到 被post，具体见全面解析9i以后Oracle Latch闩锁原理；
8i以前的latch算法可以参考：Oracle Latch:一段描绘Latch运作的伪代码
所以一般来说9i以后的 misses= Sleeps+ Spin Gets ，虽然不是绝对如此
Sleeps 是指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数
Spin Gets 以willing-to-wait模式去申请latch，在miss之后以spin方式获得了latch的次数
10-3 Latch Miss Sources
Latch Miss Sources Snaps: 70719-70723 -> only latches with sleeps are shown -> ordered by name, sleeps desc NoWait Waiter Latch Name Where Misses Sleeps Sleeps ------------------------ -------------------------- ------- ---------- -------- ASM Keyed state latch kfksolGet 0 1 1 ASM allocation kfgpnSetDisks2 0 17 0 ASM allocation kfgpnClearDisks 0 5 0 ASM allocation kfgscCreate 0 4 0 ASM allocation kfgrpGetByName 0 1 26 ASM map headers kffmUnidentify_3 0 7 8 ASM map headers kffmAllocate 0 6 0 ASM map headers kffmIdentify 0 6 11 ASM map headers kffmFree 0 1 0 ASM map operation freeli kffmTranslate2 0 15 8 ASM map operation hash t kffmUnidentify 0 44,677 36,784 ASM map operation hash t kffmTranslate 0 220 3,517
数据来源为DBA_HIST_LATCH_MISSES_SUMMARY
latch name Latch闩的名字
where : 指哪些代码路径内核函数持有过这些该latch ，而不是哪些代码路径要申请这些latch； 例如kcbgtcr函数的作用是Get a block for Consistent read，其持有latch :cache buffers chain是很正常的事情
NoWait Misses: 以no-wait模式来申请latch但直接失败的次数
Sleeps: 指latch被以willing-to-wait模式申请最终导致session需要sleep以等待该latch的次数 time of sleeps resulted in making the latch request
Waiter Sleeps：等待者休眠的次数 times of sleeps that waiters did for each where; Sleep 是阻塞者等待的次数 ， Waiter Sleeps是被阻塞者等待的次数
10-4 Mutex Sleep Summary
Mutex Sleep Summary Snaps: 70719-70723 -> ordered by number of sleeps desc Wait Mutex Type Location Sleeps Time (ms) --------------------- -------------------------------- ------------ ------------ Cursor Pin kksfbc [KKSCHLFSP2] 4,364 14,520 Cursor Pin kkslce [KKSCHLPIN2] 2,396 2,498 Library Cache kglpndl1 95 903 475 Library Cache kglpin1 4 800 458 Library Cache kglpnal2 91 799 259 Library Cache kglget1 1 553 1,697 Library Cache kglpnal1 90 489 88 Library Cache kgllkdl1 85 481 1,528 Cursor Pin kksLockDelete [KKSCHLPIN6] 410 666 Cursor Stat kkocsStoreBindAwareStats [KKSSTA 346 497 Library Cache kglhdgn2 106 167 348 Library Cache kglhdgh1 64 26 84 Library Cache kgldtin1 42 19 55 Cursor Pin kksfbc [KKSCHLPIN1] 13 34 Library Cache kglhdgn1 62 11 13 Library Cache kgllkal1 80 9 12 Library Cache kgllkc1 57 6 0 Cursor Pin kksSetBindType [KKSCHLPIN3] 5 5 Library Cache kglGetHandleReference 124 4 20 Library Cache kglUpgradeLock 119 4 0 Library Cache kglget2 2 3 0 Library Cache kglati1 45 1 0 Library Cache kglini1 32 1 0 Library Cache kglobld1 75 1 0 Library Cache kglobpn1 71 1 0
Mutex是10.2.0.2以后引入的新的内存锁机制，具体对Mutex的描述见 《深入理解Oracle中的Mutex》：http://www.askmaclean.com/archives/understanding-oracle-mutex.html
Mutex Type
Mutex的类型其实就是 mutex对应的客户的名字， 在版本10.2中基本只有KKS使用Mutex，所以仅有3种:
Cursor Stat (kgx_kks1)
Cursor Parent (kgx_kks2)
Cursor Pin (kgx_kks3)
11g中增加了Library Cache
Location 发起对该Mutex申请的代码路径code location，而不是还持有该Mutex的代码路径或曰内核函数
10.2中最常见的下面的几个函数
kkspsc0 -负责解析游标 – 检测我们正在解析的游标是否有对象的parent cursor heap 0存在
kksfbc – 负责找到合适的子游标 或者创建一个新的子游标
kksFindCursorstat
Sleeps:
Mutex的Get和Sleep
当一个Mutex被申请时， 一般称为一个get request。 若初始的申请未能得到授权， 则该进程会因为此次申请而进入到255次SPIN中(_mutex_spin_count Mutex spin count)，每次SPIN循环迭代过程中该进程都会去看看Mutex被释放了吗。
若该Mutex在SPIN之后仍未被释放，则该进程针对申请的mutex进入对应的mutex wait等待事件中。 实际进程的等待事件和等待方式由mutex的类型锁决定，例如 Cursor pin、Cursor Parent。 举例来说，这种等待可能是阻塞等待，也可以是sleep。
但是请注意在V$MUTEX_SLEEP_*视图上的sleep列意味着等待的次数。相关代码函数在开始进入等待时自加这个sleep字段。
等待计时从进程进入等待前开始计算等待时间， 当一个进程结束其等待，则等待的时间加入都总和total中。 该进程再次尝试申请之前的Mutex，若该Mutex仍不可用，则它再次进入spin/wait的循环。
V$MUTEX_SLEEP_HISTORY视图的GETS列仅在成功申请到一个Mutex时才增加。
Wait Time (ms) 类似于latch，spin time 不算做mutex的消耗时间，它只包含等待消耗的时间。
=====================================================================
11 segment statistics 段级统计
11-1 Segments by Logical Reads
Segments by Logical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Logical Reads: 2,021,476,421 -> Captured Segments account for 83.7% of Total Tablespace Subobject Obj. Logical Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 372,849,920 18.44 CONTENT_OW INDEX_TS MZ_PRODUCT__LS_PK INDEX 329,829,632 16.32 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 218,419,008 10.80 CONTENT_OW PLAYLIST_A MZ_PLAYLIST_ARTIST TABLE 182,426,240 9.02 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 108,597,376 5.37
owner : 数据段的所有者
Tablespace Name: 数据段所在表空间名
Object Name : 对象名
Subobject Name：子对象名，例如一个分区表的某个分区
obj Type: 对象类型 一般为TABLE /INDEX 或者分区或子分区
Logical Reads ：该数据段上发生过的逻辑读 ， 单位为 块数*次数
%Total : 占总的逻辑读的百分比 ， (当前对象上发生过的逻辑读/ Total DB 逻辑读)
11-2 Segments by Physical Reads
Segments by Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Reads: 56,839,035 -> Captured Segments account for 51.9% of Total Tablespace Subobject Obj. Physical Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW SONG_TS MZ_SONG TABLE 7,311,928 12.86 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 4,896,554 8.61 CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 3,099,387 5.45 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,529,971 2.69 CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 1,391,735 2.45
Physical Reads: 该数据段上发生过的物理读 ， 单位为 块数*次数
%Total : 占总的物理读的百分比 ， (当前对象上发生过的逻辑读/ Total DB 逻辑读)
11-3 Segments by Physical Read Requests
Segments by Physical Read Requests DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Read Requests: 33,936,360 -> Captured Segments account for 45.5% of Total Tablespace Subobject Obj. Phys Read Owner Name Object Name Name Type Requests %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 3,099,346 9.13 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,529,950 4.51 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 1,306,756 3.85 CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE 910,537 2.68 CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 820,459 2.42
Phys Read Requests ： 物理读的申请次数
%Total ： (该段上发生的物理读的申请次数/ physical read IO requests)
11-4 Segments by UnOptimized Reads
Segments by UnOptimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total UnOptimized Read Requests: 811,466 -> Captured Segments account for 58.5% of Total Tablespace Subobject Obj. UnOptimized Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 103,580 12.76 CONTENT_OW SONG_TS MZ_SONG TABLE 56,946 7.02 CONTENT_OW DATA_TS MZ_IMAGE TABLE 47,017 5.79 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 40,950 5.05 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 30,406 3.75
UnOptimized Reads UnOptimized Read Reqs = Physical Read Reqts – Optimized Read Reqs
Optimized Read Requests是指 哪些满足Exadata Smart Flash Cache ( or the Smart Flash Cache in OracleExadata V2 (Note that despite same name, concept and use of
‘Smart Flash Cache’ in Exadata V2 is different from ‘Smart Flash Cache’ in Database Smart Flash Cache)).的物理读 次数 。 满足从smart flash cache走的读取申请呗认为是optimized ，因为这些读取要比普通从磁盘走快得多。
此外通过smart scan 读取storage index的情况也被认为是’optimized read requests’ ，源于可以避免读取不相关的数据。
当用户不在使用Exadata时，则UnOptimized Read Reqs总是等于 Physical Read Reqts
%Total : (该段上发生的物理读的UnOptimized Read Reqs / ( physical read IO requests – physical read requests optimized ))
11-5 Segments by Optimized Reads
Segments by Optimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Optimized Read Requests: 33,124,894 -> Captured Segments account for 45.2% of Total Tablespace Subobject Obj. Optimized Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 2,995,766 9.04 CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,489,000 4.50 CONTENT_OW DATA_TS MZ_PRODUCT TABLE 1,276,350 3.85 CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE 890,775 2.69 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 816,067 2.46
关于optimizerd read 上面已经解释过了，这里的单位是 request 次数
%Total : (该段上发生的物理读的 Optimized Read Reqs/ physical read requests optimized )
11-6 Segments by Direct Physical Reads
Segments by Direct Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Direct Physical Reads: 14,118,552 -> Captured Segments account for 94.2% of Total Tablespace Subobject Obj. Direct Owner Name Object Name Name Type Reads %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW SONG_TS MZ_SONG TABLE 7,084,416 50.18 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 4,839,984 34.28 CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 1,361,133 9.64 CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 5,904 .04 CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 1,656 .01
Direct reads 直接路径物理读，单位为 块数*次数
%Total (该段上发生的direct path reads /Total physical reads direct )
11-7 Segments by Physical Writes
Segments by Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Writes: 590,563 -> Captured Segments account for 38.3% of Total Tablespace Subobject Obj. Physical Owner Name Object Name Name Type Writes %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 23,595 4.00 CONTENT_OW DATA_TS MZ_PODCAST TABLE 19,834 3.36 CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX 16,345 2.77 SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE 14,173 2.40 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 9,645 1.63
Physical Writes ，物理写 单位为 块数*次数
Total % (该段上发生的物理写 /Total physical writes )
11-9 Segments by Physical Write Requests
Segments by Physical Write Requests DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Physical Write Requestss: 436,789 -> Captured Segments account for 43.1% of Total Tablespace Subobject Obj. Phys Write Owner Name Object Name Name Type Requests %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 22,581 5.17 CONTENT_OW DATA_TS MZ_PODCAST TABLE 19,797 4.53 CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX 14,529 3.33 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 9,434 2.16 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 8,618 1.97
Phys Write Requests 物理写的请求次数 ，单位为次数
%Total (该段上发生的物理写请求次数 /physical write IO requests )
11-10 Segments by Direct Physical Writes
Segments by Direct Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Direct Physical Writes: 29,660 -> Captured Segments account for 18.3% of Total Tablespace Subobject Obj. Direct Owner Name Object Name Name Type Writes %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE 4,601 15.51 CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 620 2.09 CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 134 .45 CONTENT_OW DATA_TS SYS_LOB0000203779C00 LOB 46 .16 CONTENT_OW DATA_TS SYS_LOB0000203796C00 LOB 41 .14
Direct Writes 直接路径写， 单位额为块数*次数
%Total 为(该段上发生的直接路径写 /physical writes direct )
11-11 Segments by Table Scans
Segments by Table Scans DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Table Scans: 10,713 -> Captured Segments account for 1.0% of Total Tablespace Subobject Obj. Table Owner Name Object Name Name Type Scans %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 92 .86 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 14 .13 CONTENT_OW SONG_TS MZ_SONG TABLE 3 .03 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 1 .01
Table Scans 来源为dba_hist_seg_stat.table_scans_delta 不过这个指标并不十分精确
11-12 Segments by DB Blocks Changes
Segments by DB Blocks Changes DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of DB Block Changes for each top segment compared -> with total DB Block Changes for all segments captured by the Snapshot Tablespace Subobject Obj. DB Block % of Owner Name Object Name Name Type Changes Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX 347,856 10.21 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 269,504 7.91 CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX 251,904 7.39 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 201,056 5.90 CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX 199,888 5.86
DB Block Changes ，单位为块数*次数
%Total : (该段上发生block changes / db block changes )
11-13 Segments by Row Lock Waits
Segments by Row Lock Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of row lock waits for each top segment compared -> with total row lock waits for all segments captured by the Snapshot Row Tablespace Subobject Obj. Lock % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 72,005 43.86 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 13,795 8.40 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 12,383 7.54 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 8,937 5.44 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 8,531 5.20
Row Lock Waits 是指行锁的等待次数 数据来源于 dba_hist_seg_stat.ROW_LOCK_WAITS_DELTA
11-14 Segments by ITL WAITS
Segments by ITL Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of ITL waits for each top segment compared -> with total ITL waits for all segments captured by the Snapshot Tablespace Subobject Obj. ITL % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 95 30.16 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 48 15.24 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 21 6.67 CONTENT_OW INDEX_TS MZ_SALABLE_FIRST_AVA INDEX 21 6.67 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 20 6.35
关于 ITL的介绍详见： http://www.askmaclean.com/archives/enqueue-tx-row-lock-index-itl-wait-event.html
ITL Waits 等待 ITL 的次数，数据来源为 dba_hist_seg_stat.itl_waits_delta
11-14 Segments by Buffer Busy Waits
Segments by Buffer Busy Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> % of Capture shows % of Buffer Busy Waits for each top segment compared -> with total Buffer Busy Waits for all segments captured by the Snapshot Buffer Tablespace Subobject Obj. Busy % of Owner Name Object Name Name Type Waits Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 251,073 57.07 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 36,186 8.23 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 31,786 7.23 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 15,663 3.56 CONTENT_OW INDEX_TS MZ_CS_WORK_PENDING_R INDEX 11,087 2.52
Buffer Busy Waits 该数据段上发生 buffer busy wait的次数 数据来源 dba_hist_seg_stat.buffer_busy_waits_delta
11-15 Segments by Global Cache Buffer
Segments by Global Cache Buffer BusyDB/Inst: MAC/MAC2 Snaps: 70719-7072 -> % of Capture shows % of GC Buffer Busy for each top segment compared -> with GC Buffer Busy for all segments captured by the Snapshot GC Tablespace Subobject Obj. Buffer % of Owner Name Object Name Name Type Busy Capture ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 2,135,528 50.07 CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 652,900 15.31 CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 552,161 12.95 CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 113,042 2.65 CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 98,134 2.30
GC Buffer Busy 数据段上发挥僧gc buffer busy的次数， 数据源 dba_hist_seg_stat.gc_buffer_busy_delta
11-15 Segments by CR Blocks Received
Segments by CR Blocks Received DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total CR Blocks Received: 763,037 -> Captured Segments account for 40.9% of Total CR Tablespace Subobject Obj. Blocks Owner Name Object Name Name Type Received %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 69,100 9.06 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 44,491 5.83 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 36,830 4.83 CONTENT_OW DATA_TS MZ_PODCAST TABLE 36,632 4.80 CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX 19,646 2.57
CR Blocks Received ：是指RAC中本地节点接收到global cache CR blocks 的数量； 数据来源为 dba_hist_seg_stat.gc_cu_blocks_received_delta
%Total : (该段上在本节点接收的Global CR blocks / gc cr blocks received )
11-16 Segments by Current Blocks Received
Segments by Current Blocks ReceivedDB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Total Current Blocks Received: 704,731 -> Captured Segments account for 61.8% of Total Current Tablespace Subobject Obj. Blocks Owner Name Object Name Name Type Received %Total ---------- ---------- -------------------- ---------- ----- ------------ ------- CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 56,287 7.99 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 45,139 6.41 CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 40,350 5.73 CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 22,808 3.24 CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX 13,343 1.89
Current Blocks Received :是指RAC中本地节点接收到global cache Current blocks 的数量 ，数据来源DBA_HIST_SEG_STAT.gc_cu_blocks_received_delta
%Total : (该段上在本节点接收的 global cache current blocks / gc current blocks received)
12 Dictionary Cache Stats
Dictionary Cache Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> "Pct Misses" should be very low (< 2% in most cases) -> "Final Usage" is the number of cache entries being used Get Pct Scan Pct Mod Final Cache Requests Miss Reqs Miss Reqs Usage ------------------------- ------------ ------ ------- ----- -------- ---------- dc_awr_control 87 2.3 0 N/A 6 1 dc_global_oids 1,134 7.8 0 N/A 0 13 dc_histogram_data 6,119,027 0.9 0 N/A 0 11,784 dc_histogram_defs 1,898,714 2.3 0 N/A 0 5,462 dc_object_grants 175 26.9 0 N/A 0 4 dc_objects 10,254,514 0.2 0 N/A 0 3,807 dc_profiles 8,452 0.0 0 N/A 0 2 dc_rollback_segments 3,031,044 0.0 0 N/A 0 1,947 dc_segments 1,812,243 1.4 0 N/A 10 3,595 dc_sequences 15,783 69.6 0 N/A 15,782 20 dc_table_scns 70 2.9 0 N/A 0 1 dc_tablespaces 1,628,112 0.0 0 N/A 0 37 dc_users 2,037,138 0.0 0 N/A 0 52 global database name 7,698 0.0 0 N/A 0 1 outstanding_alerts 264 99.6 0 N/A 8 1 sch_lj_oids 51 7.8 0 N/A 0 1
Dictionary Cache 字典缓存也叫row cache
数据来源为dba_hist_rowcache_summary
Cache 字典缓存类名kqrstcid <=> kqrsttxt cid=3(dc_rollback_segments)
Get Requests 申请获取该数据字典缓存对象的次数 gets
Miss : GETMISSES 申请获取该数据字典缓存对象但 miss的次数
Pct Miss ： GETMISSES /Gets ， Miss的比例 ，这个pct miss应当非常低 小于2%，否则有出现大量row cache lock的可能
Scan Reqs：扫描申请的次数 ，kqrssc 、kqrpScan 、kqrpsiv时发生scan 会导致扫描数增加 kqrstsrq++(scan requests) ，例如migrate tablespace 时调用 kttm2b函数 为了安全删除uet$中的记录会callback kqrpsiv (used extent cache)，实际很少见
Pct Miss：SCANMISSES/SCANS
Mod Reqs: 申请修改字典缓存对象的次数，从上面的数据可以看到dc_sequences的mod reqs很高，这是因为sequence是变化较多的字典对象
Final Usage ：包含有有效数据的字典缓存记录的总数 也就是正在被使用的row cache记录 USAGE Number of cache entries that contain valid data
Dictionary Cache Stats (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723 GES GES GES Cache Requests Conflicts Releases ------------------------- ------------ ------------ ------------ dc_awr_control 14 2 0 dc_global_oids 88 0 102 dc_histogram_defs 43,518 0 43,521 dc_objects 21,608 17 21,176 dc_profiles 1 0 1 dc_segments 24,974 14 24,428 dc_sequences 25,178 10,644 347 dc_table_scns 2 0 2 dc_tablespaces 165 0 166 dc_users 119 0 119 outstanding_alerts 478 8 250 sch_lj_oids 4 0 4
GES Request kqrstilr total instance lock requests ，通过全局队列服务GES 来申请instance lock的次数
GES request 申请的原因可能是 dump cache object、kqrbfr LCK进程要background free some parent objects释放一些parent objects 等
GES Conflicts kqrstifr instance lock forced-releases ， LCK进程以AST方式 释放锁的次数 ，仅出现在kqrbrl中
GES Releases kqrstisr instance lock self-releases ，LCK进程要background free some parent objects释放一些parent objects 时可能自增
上述数据中可以看到仅有dc_sequences 对应的GES Conflicts较多， 对于sequence 使用ordered和non-cache选项会导致RAC中的一个边际效应，即”row cache lock”等待源于DC_SEQUENCES ROW CACHE。 DC_SEQUENCES 上的GETS request、modifications 、GES requests和GES conflict 与引发生成一个新的 sequence number的特定SQL执行频率相关。
在Oracle 10g中，ORDERED Sequence还可能在高并发下造成大量DFS lock Handle 等待，由于bug 5209859
13 Library Cache Activity
Library Cache Activity DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> "Pct Misses" should be very low Get Pct Pin Pct Invali- Namespace Requests Miss Requests Miss Reloads dations --------------- ------------ ------ -------------- ------ ---------- -------- ACCOUNT_STATUS 8,436 0.3 0 N/A 0 0 BODY 8,697 0.7 15,537 0.7 49 0 CLUSTER 317 4.7 321 4.7 0 0 DBLINK 9,212 0.1 0 N/A 0 0 EDITION 4,431 0.0 8,660 0.0 0 0 HINTSET OBJECT 1,027 9.5 1,027 14.4 0 0 INDEX 792 18.2 792 18.2 0 0 QUEUE 10 0.0 1,733 0.0 0 0 RULESET 0 N/A 8 87.5 7 0 SCHEMA 8,169 0.0 0 N/A 0 0 SQL AREA 533,409 4.8 -4,246,727,944 101.1 44,864 576 SQL AREA BUILD 71,500 65.5 0 N/A 0 0 SQL AREA STATS 41,008 90.3 41,008 90.3 1 0 TABLE/PROCEDURE 320,310 0.6 1,033,991 3.6 25,378 0 TRIGGER 847 0.0 38,442 0.3 110 0
NameSpace library cache 的命名空间
GETS Requests 该命名空间所包含对象的library cache lock被申请的次数
GETHITS 对象的 library cache handle 正好在内存中被找到的次数
Pct Misses : ( 1- ( GETHITS /GETS Requests)) *100
Pin Requests 该命名空间所包含对象上pin被申请的次数
PINHITS 要pin的对象的heap metadata正好在shared pool中的次数
Pct Miss ( 1- ( PINHITS /Pin Requests)) *100
Reloads 指从object handle 被重建开始不是第一次PIN该对象的PIN ，且该次PIN要求对象从磁盘上读取加载的次数 ;Reloads值较高的情况 建议增大shared_pool_size
INVALIDATIONS 由于以来对象被修改导致该命名空间所包含对象被标记为无效的次数
Library Cache Activity (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723 GES Lock GES Pin GES Pin GES Inval GES Invali- Namespace Requests Requests Releases Requests dations --------------- ------------ ------------ ------------ ----------- ----------- ACCOUNT_STATUS 8,436 0 0 0 0 BODY 0 15,497 15,497 0 0 CLUSTER 321 321 321 0 0 DBLINK 9,212 0 0 0 0 EDITION 4,431 4,431 4,431 0 0 HINTSET OBJECT 1,027 1,027 1,027 0 0 INDEX 792 792 792 0 0 QUEUE 8 1,733 1,733 0 0 RULESET 0 8 8 0 0 SCHEMA 4,226 0 0 0 0 TABLE/PROCEDURE 373,163 704,816 704,816 0 0 TRIGGER 0 38,430 38,430 0 0
GES Lock Request: dlm_lock_requests Lock instance-lock ReQuests 申请获得lock instance lock的次数
GES PIN request : DLM_PIN_REQUESTS Pin instance-lock ReQuests 申请获得pin instance lock的次数
GES Pin Releases DLM_PIN_RELEASES release the pin instance lock 释放pin instance lock的次数
GES Inval Requests DLM_INVALIDATION_REQUESTS get the invalidation instance lock 申请获得invalidation instance lock的次数
GES Invali- dations DLM_INVALIDATIONS 接收到其他节点的invalidation pings次数
14 Process Memory Summary
Process Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> B: Begin Snap E: End Snap -> All rows below contain absolute values (i.e. not diffed over the interval) -> Max Alloc is Maximum PGA Allocation size at snapshot time -> Hist Max Alloc is the Historical Max Allocation for still-connected processes -> ordered by Begin/End snapshot, Alloc (MB) desc Hist Avg Std Dev Max Max Alloc Used Alloc Alloc Alloc Alloc Num Num Category (MB) (MB) (MB) (MB) (MB) (MB) Proc Alloc - -------- --------- --------- -------- -------- ------- ------- ------ ------ B Other 16,062.7 N/A 6.1 66.6 3,370 3,370 2,612 2,612 SQL 5,412.2 4,462.9 2.2 89.5 4,483 4,483 2,508 2,498 Freeable 2,116.4 .0 .9 6.3 298 N/A 2,266 2,266 PL/SQL 94.0 69.8 .0 .0 1 1 2,610 2,609 E Other 15,977.3 N/A 6.1 66.9 3,387 3,387 2,616 2,616 SQL 5,447.9 4,519.0 2.2 89.8 4,505 4,505 2,514 2,503 Freeable 2,119.9 .0 .9 6.3 297 N/A 2,273 2,273 PL/SQL 93.2 69.2 .0 .0 1 1 2,614 2,613
数据来源为dba_hist_process_mem_summary， 这里是对PGA 使用的一个小结，帮助我们了解到底谁用掉了PGA
B: 开始快照 E: 结束快照
该环节列出 PGA中各分类的使用量
Category 分类名，包括”SQL”, “PL/SQL”, “OLAP” 和”JAVA”. 特殊分类是 “Freeable” 和”Other”. Free memory是指哪些 OS已经分配给进程，但没有分配给任何分类的内存。 “Other”是已经分配给分类的内存，但不是已命名的分类
Alloc (MB) allocated_total 该分类被分配的总内存
Used (MB) used_total 该分类已使用的内存
Avg Alloc (MB) allocated_avg 平均每个进程中该分类分配的内存量
Std Dev Alloc (MB) ：该分类分配的内存在每个进程之间的标准差
Max Alloc (MB) ALLOCATED_MAX ：在快照时间内单个进程该分类最大分配过的内存量：Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc (MB) MAX_ALLOCATED_MAX: 目前仍链接着的进程该分类最大分配过的内存量：Hist Max Alloc is the Historical Max Allocation for still-connected processes
Num Proc num_processes 进程数目
Num Alloc NON_ZERO_ALLOCS 分配了该类型 内存的进程数目
14 SGA信息
14 -1 SGA Memory Summary
SGA Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723 End Size (Bytes) SGA regions Begin Size (Bytes) (if different) ------------------------------ ------------------- ------------------- Database Buffers 20,669,530,112 Fixed Size 2,241,880 Redo Buffers 125,669,376 Variable Size 10,536,094,376 ------------------- sum 31,333,535,744
粗粒度的sga区域内存使用信息， End Size仅在于begin size不同时打印
14-2 SGA breakdown difference
SGA breakdown difference DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> ordered by Pool, Name -> N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshot Pool Name Begin MB End MB % Diff ------ ------------------------------ -------------- -------------- ------- java free memory 64.0 64.0 0.00 large PX msg pool 7.8 7.8 0.00 large free memory 247.8 247.8 0.00 shared Checkpoint queue 140.6 140.6 0.00 shared FileOpenBlock 2,459.2 2,459.2 0.00 shared KGH: NO ACCESS 1,629.6 1,629.6 0.00 shared KGLH0 997.7 990.5 -0.71 shared KKSSP 312.2 308.9 -1.06 shared SQLA 376.6 370.6 -1.61 shared db_block_hash_buckets 178.0 178.0 0.00 shared dbktb: trace buffer 156.3 156.3 0.00 shared event statistics per sess 187.1 187.1 0.00 shared free memory 1,208.9 1,220.6 0.97 shared gcs resources 435.0 435.0 0.00 shared gcs shadows 320.6 320.6 0.00 shared ges enqueues 228.9 228.9 0.00 shared ges resource 118.3 118.3 0.00 shared init_heap_kfsg 1,063.6 1,068.1 0.43 shared kglsim object batch 124.3 124.3 0.00 shared ksunfy : SSO free list 174.7 174.7 0.00 stream free memory 128.0 128.0 0.00 buffer_cache 19,712.0 19,712.0 0.00 fixed_sga 2.1 2.1 0.00 log_buffer 119.8 119.8 0.00 -------------------------------------------------------------
Pool 内存池的名字
Name 内存池中细分组件的名字 例如KGLH0 存放KEL Heap 0 、SQLA存放SQL执行计划等
Begin MB 快照开始时该组件的内存大小
End MB 快照结束时该组件的内存大小
% Diff 差异百分比
特别注意 由于AMM /ASMM引起的shared pool收缩 一般在sga breakdown中可以提现 例如SQLA 、KQR等组件大幅缩小 ，可能导致一系列的解析等待 cursor: Pin S on X 、row cache lock等
此处的free memory信息也值得我们关注， 一般推荐shared pool应当有300~400 MB 的free memory为宜
15 Streams统计
Streams CPU/IO Usage DB/Inst: ORCL/orcl1 Snaps: 556-559 -> Streams processes ordered by CPU usage -> CPU and I/O Time in micro seconds Session Type CPU Time User I/O Time Sys I/O Time ------------------------- -------------- -------------- -------------- QMON Coordinator 101,698 0 0 QMON Slaves 63,856 0 0 ------------------------------------------------------------- Streams Capture DB/Inst: CATGT/catgt Snaps: 911-912 -> Lag Change should be small or negative (in seconds) Captured Enqueued Pct Pct Pct Pct Per Per Lag RuleEval Enqueue RedoWait Pause Capture Name Second Second Change Time Time Time Time ------------ -------- -------- -------- -------- -------- -------- -------- CAPTURE_CAT 650 391 93 0 23 0 71 ------------------------------------------------------------- Streams Apply DB/Inst: CATGT/catgt Snaps: 911-912 -> Pct DB is the percentage of all DB transactions that this apply handled -> WDEP is the wait for dependency -> WCMT is the wait for commit -> RBK is rollbacks -> MPS is messages per second -> TPM is time per message in milli-seconds -> Lag Change should be small or negative (in seconds) Applied Pct Pct Pct Pct Applied Dequeue Apply Lag Apply Name TPS DB WDEP WCMT RBK MPS TPM TPM Change ------------ -------- ---- ---- ---- --- -------- -------- -------- -------- APPLY_CAT 0 0 0 0 0 0 0 0 0 -------------------------------------------------------------
Capture Name : Streams捕获进程名
Captured Per Second ：每秒挖掘出来的message 条数
Enqueued Per Second: 每秒入队的message条数
lag change: 指日志生成的时间到挖掘到该日志生成 message的时间延迟
Pct Enqueue Time： 入队时间的比例
Pct redoWait Time : 等待redo的时间比例
Pct Pause Time : Pause 时间的比例
Apply Name Streams 应用Apply进程的名字
Applied TPS : 每秒应用的事务数
Pct DB: 所有的DB事务中 apply处理的比例
Pct WDEP: 由于等待依赖的数据而耗费的时间比例
Pct WCMT: 由于等待commit而耗费的时间比例
Pct RBK: 事务rollback 回滚的比例
Applied MPS: 每秒应用的message 数
Dequeue TPM: 每毫秒出队的message数
Lag Change:指最新message生成的时间到其被Apply收到的延迟
16 Resource Limit
Resource Limit Stats DB/Inst: MAC/MAC2 Snap: 70723 -> 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 ------------------------------ ------------ ------------ ---------- ---------- ges_procs 2,612 8,007 10003 10003 processes 2,615 8,011 10000 10000
数据源于dba_hist_resource_limit
注意这里仅列出当前使用或最大使用量>80% *最大限制的资源名，如果没有列在这里则说明 资源使用量安全
Current Utilization 当前对该资源(包括Enqueue Resource、Lock和processes)的使用量
Maximum Utilization 从最近一次实例启动到现在该资源的最大使用量
Initial Allocation 初始分配值，一般等于参数文件中指定的值
Limit 实际上限值
17 init.ora Parameters
init.ora Parameters DB/Inst: MAC/MAC2 Snaps: 70719-70723 End value Parameter Name Begin value (if different) ----------------------------- --------------------------------- -------------- _compression_compatibility 11.2.0 _kghdsidx_count 4 _ksmg_granule_size 67108864 _shared_pool_reserved_min_all 4100 archive_lag_target 900 audit_file_dest /u01/app/oracle/admin/MAC/adum audit_trail OS cluster_database TRUE compatible 11.2.0.2.0 control_files +DATA/MAC/control01.ctl, +RECO db_16k_cache_size 268435456 db_block_size 8192 db_cache_size 19327352832 db_create_file_dest +DATA
Parameter Name 参数名
Begin value 开始快照时的参数值
End value 结束快照时的参数值 (仅在发生变化时打印)
18 Global Messaging Statistics
Global Messaging Statistics DB/Inst: MAC/MAC2 Snaps: 70719-70723 Statistic Total per Second per Trans --------------------------------- ---------------- ------------ ------------ acks for commit broadcast(actual) 53,705 14.9 0.2 acks for commit broadcast(logical 311,182 86.1 1.3 broadcast msgs on commit(actual) 317,082 87.7 1.3 broadcast msgs on commit(logical) 317,082 87.7 1.3 broadcast msgs on commit(wasted) 263,332 72.9 1.1 dynamically allocated gcs resourc 0 0.0 0.0 dynamically allocated gcs shadows 0 0.0 0.0 flow control messages received 267 0.1 0.0 flow control messages sent 127 0.0 0.0 gcs apply delta 0 0.0 0.0 gcs assume cvt 55,541 15.4 0.2
全局通信统计信息，数据来源WRH$_DLM_MISC;
20 Global CR Served Stats
Global CR Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 Statistic Total ------------------------------ ------------------ CR Block Requests 403,703 CURRENT Block Requests 444,896 Data Block Requests 403,705 Undo Block Requests 94,336 TX Block Requests 307,896 Current Results 652,746 Private results 21,057 Zero Results 104,720 Disk Read Results 69,418 Fail Results 508 Fairness Down Converts 102,844 Fairness Clears 15,207 Free GC Elements 0 Flushes 105,052 Flushes Queued 0 Flush Queue Full 0 Flush Max Time (us) 0 Light Works 71,793 Errors 117
LMS传输CR BLOCK的统计信息，数据来源WRH$_CR_BLOCK_SERVER
21 Global CURRENT Served Stats
Global CURRENT Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Pins = CURRENT Block Pin Operations -> Flushes = Redo Flush before CURRENT Block Served Operations -> Writes = CURRENT Block Fusion Write Operations Statistic Total % <1ms % <10ms % <100ms % <1s % <10s ---------- ------------ -------- -------- -------- -------- -------- Pins 73,018 12.27 75.96 8.49 2.21 1.08 Flushes 79,336 5.98 50.17 14.45 19.45 9.95 Writes 102,189 3.14 35.23 19.34 33.26 9.03
数据来源dba_hist_current_block_server
Time to process current block request = (pin time + flush time + send time)
Pins CURRENT Block Pin Operations ， PIN的内涵是处理一个BAST 不包含对global current block的flush和实际传输
The pin time represents how much time is required to process a BAST. It does not include the flush time and
the send time. The average pin time per block served should be very low because the processing consists
mainly of code path and should never be blocked.
Flush 指 脏块被LMS进程传输出去之前，其相关的redo必须由LGWR已经flush 到磁盘上
Write 指fusion write number of writes which were mediated； 节点之间写脏块需求相互促成的行为 KJBL.KJBLREQWRITE gcs write request msgs 、gcs writes refused
% <1ms % <10ms % <100ms % <1s % <10s 分别对应为pin、flush、write行为耗时的比例
例如在上例中flush和 write 在1s 到10s之间的有9%，在100ms 和1s之间的有19%和33%，因为flush和write都是IO操作 所以这里可以预见IO存在问题，延迟较高
22 Global Cache Transfer Stats
Global Cache Transfer Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723 -> Immediate (Immed) - Block Transfer NOT impacted by Remote Processing Delays -> Busy (Busy) - Block Transfer impacted by Remote Contention -> Congested (Congst) - Block Transfer impacted by Remote System Load -> ordered by CR + Current Blocks Received desc CR Current ----------------------------- ----------------------------- Inst Block Blocks % % % Blocks % % % No Class Received Immed Busy Congst Received Immed Busy Congst ---- ----------- -------- ------ ------ ------ -------- ------ ------ ------ 1 data block 133,187 76.3 22.6 1.1 233,138 75.2 23.0 1.7 4 data block 143,165 74.1 24.9 1.0 213,204 76.6 21.8 1.6 3 data block 122,761 75.9 23.0 1.1 220,023 77.7 21.0 1.3 1 undo header 104,219 95.7 3.2 1.1 941 93.4 5.8 .7 4 undo header 95,823 95.2 3.7 1.1 809 93.4 5.3 1.2 3 undo header 95,592 95.6 3.3 1.1 912 94.6 4.5 .9 1 undo block 25,002 95.8 3.4 .9 0 N/A N/A N/A 4 undo block 23,303 96.0 3.1 .9 0 N/A N/A N/A 3 undo block 21,672 95.4 3.7 .9 0 N/A N/A N/A 1 Others 1,909 92.0 6.8 1.2 6,057 89.6 8.9 1.5 4 Others 1,736 92.4 6.1 1.5 5,841 88.8 9.9 1.3 3 Others 1,500 92.4 5.9 1.7 4,405 87.7 10.8 1.6
数据来源DBA_HIST_INST_CACHE_TRANSFER
Inst No 节点号
Block Class 块的类型
CR Blocks Received 该节点上 该类型CR 块的接收数量
CR Immed %: CR块请求立即接收到的比例
CR Busy%：CR块请求由于远端争用而没有立即接收到的比例
CR Congst%: CR块请求由于远端负载高而没有立即接收到的比例
Current Blocks Received 该节点上 该类型Current 块的接收数量
Current Immed %: Current块请求立即接收到的比例
Current Busy%：Current块请求由于远端争用而没有立即接收到的比例
Current Congst%: Current块请求由于远端负载高而没有立即接收到的比例
Congst%的比例应当非常低 不高于2%， Busy%很大程度受到IO的影响，如果超过10% 一般会有严重的gc buffer busy acquire/release
参考文档
Statistics Descriptions http://docs.oracle.com/cd/B19306_01/server.102/b14237/stats002.htm
Memory Configuration and Use http://docs.oracle.com/cd/B19306_01/server.102/b14211/memory.htm
Library Cache Hit (%) http://docs.oracle.com/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_instance_efficiency_libcache_hit_pct.html
Oracle? Database Performance Tuning Guide 12c Release 1 (12.1)
How to Interpret the “SQL ordered by Physical Reads (UnOptimized)” Section in AWR Reports (11.2 onwards) [ID 1466035.1]
感谢原作者：http://blog.itpub.net/26954807/viewspace-1300697/
转载于:https://blog.51cto.com/yfshare/1689188
499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
