Oracle AWR报告详细分析

2020年09月19日 阅读数:119
这篇文章主要向大家介绍Oracle AWR报告详细分析,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

Oracle AWR报告详细分析  (文档 ID 1523048.1)




AWR 是 Oracle  10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库
AWR 是经过对比两次快
照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分。

WORKLOAD REPOSITORY report for 

DB Name html

DB Id 前端

Instance java

Inst num node

Release ios

RAC 算法

Host sql

ICCI 数据库

1314098396 数组

ICCI1 缓存

1

10.2.0.3.0

YES

HPGICCI1

  

 

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

2678

25-Dec-08 14:04:50

24

1.5

End Snap:

2680

25-Dec-08 15:23:37

26

1.5

Elapsed:

 

78.79 (mins)

 

 

DB Time:

 

11.05 (mins)

 

 


DB Time不包括Oracle后台进程消耗的时间。若是DB Time远远小于Elapsed时间,说明数据库比较空闲。
db time= cpu time + wait time(不包含空闲等待) (非后台进程)
说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间
DB time = cpu time + all of nonidle wait event time


79分钟里(其间收集了3次快照数据),数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU4个物理CPU),
平均每一个
CPU耗时1.4分钟,CPU利用率只有大约2%1.4/79)。说明系统压力很是小。

 

列出下面这两个来作解释:
Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)

Report B:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 40 16.4
Elapsed: 59.63 (mins)
DB Time: 19.49 (mins)



服务器是AIX的系统,4个双核cpu,8个核:

/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7


先说Report A,snapshot间隔中,总共约60分钟,cpu就共有60*8=480分钟,DB time466.37分钟
则:
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu 466.37/480*100% 花费在处理Oracle的操做上,这还不包括后台进程
Report B,总共约60分钟,cpu 19.49/480*100% 花费在处理Oracle的操做上
很显然,Report B中服务器的平均负载很低。
awr reportElapsed timeDB Time就能大概了解db的负载。


但是对于批量系统,数据库的工做负载老是集中在一段时间内。若是快照周期不在这一段时间内,
或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的.
这也说明选择分析时间段很关键,要选择可以表明性能问题的时间段。

 

Report Summary

Cache Sizes

 

Begin

End

 

 

Buffer Cache:

3,344M

3,344M

Std Block Size:

8K

Shared Pool Size:

704M

704M

Log Buffer:

14,352K


显示
SGA中每一个区域的大小(在AMM改变它们以后),可用来与初始参数值比较。

shared pool主要包括library cachedictionary cache
library cache用来存储最近解析(或编译)后SQLPL/SQLJava classes等。
dictionary cache
用来存储最近引用的数据字典。
发生在
library cachedictionary cachecache miss代价要比发生在buffer cache的代价高得多。
所以
shared pool的设置要确保最近使用的数据都能被cache

 

Load Profile

 

Per Second

Per Transaction

Redo size:

918,805.72

775,912.72

Logical reads:

3,521.77

2,974.06

Block changes:

1,817.95

1,535.22

Physical reads:

68.26

57.64

Physical writes:

362.59

306.20

User calls:

326.69

275.88

Parses:

38.66

32.65

Hard parses:

0.03

0.03

Sorts:

0.61

0.51

Logons:

0.01

0.01

Executes:

354.34

299.23

Transactions:

1.18

 

 

% Blocks changed per Read:

51.62

Recursive Call %:

51.72

Rollback per transaction %:

85.49

Rows per Sort:

########


显示数据库负载概况,将之与基线数据比较才具备更多的意义,若是每秒或每事务的负载变化不大,说明应用运行比较稳定。
单个的报告数据只说明应用的负载状况,绝大多数据并无一个所谓“正确”的值,然而
Logons大于每秒1~2个、Hard parses大于每秒100、所有parses超过每秒300代表可能有争用问题


Redo size每秒产生的日志大小(单位字节),可标志数据变动频率, 数据库任务的繁重与否。

Logical reads:每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB Block Gets


Block changes:每秒/每事务修改的块数


Physical reads:每秒/每事务物理读的块数


Physical writes:每秒/每事务物理写的块数


User calls:每秒/每事务用户call次数


ParsesSQL解析的次数.每秒解析次数,包括fast parsesoft parsehard parse三种数量的综合。 
软解析每秒超过300次意味着你的"应用程序"效率不高,调整session_cursor_cache
在这里,fast parse指的是直接在PGA中命中的状况(设置了session_cached_cursors=n);
soft parse是指在shared pool中命中的情形;hard parse则是指都不命中的状况。


Hard parses:其中硬解析的次数,硬解析太多,说明SQL重用率不高。
每秒产生的硬解析次数, 每秒超过100次,就可能说明你绑定使用的很差,也多是共享池设置不合理。
这时候能够启用参数cursor_sharing=similar|force,该参数默认值为exact。但该参数设置为similar时,存在bug,可能致使执行计划的不优。


Sorts:每秒/每事务的排序次数


Logons:每秒/每事务登陆的次数


Executes:每秒/每事务SQL执行次数


Transactions:每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。

 
Blocks changed per Read:表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。


Recursive Call:递归调用占全部操做的比率.递归调用的百分比,若是有不少PL/SQL,那么这个值就会比较高。


Rollback per transaction:每事务的回滚率.看回滚率是否是很高,由于回滚很耗资源 ,若是回滚率太高,
可能说明你的数据库经历了太多的无效操做 ,过多的回滚可能还会带来Undo Block的竞争 
该参数计算公式以下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。


Rows per Sort:每次排序的行数


:

Oracle的硬解析和软解析

  提到软解析(soft prase)和硬解析(hard prase),就不能不说一下Oraclesql的处理过程。
当你发出一条
sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程:

  1、语法检查(syntax check)

  检查此sql的拼写是否语法。

  2、语义检查(semantic check)

  诸如检查sql语句中的访问对象是否存在及该用户是否具有相应的权限。

  3、对sql语句进行解析(prase)

  利用内部算法对sql进行解析,生成解析树(parse tree)及执行计划(execution plan)

  4、执行sql,返回结果(execute and return)

  其中,软、硬解析就发生在第三个过程里。

  Oracle利用内部的hash算法来取得该sqlhash值,而后在library cache里查找是否存在该hash值;

  假设存在,则将此sqlcache中的进行比较;

  假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关工做。这也就是软解析的过程。

  诚然,若是上面的2个假设中任有一个不成立,那么优化器都将进行建立解析树、生成执行计划的动做。这个过程就叫硬解析。

建立解析树、生成执行计划对于sql的执行来讲是开销昂贵的动做,因此,应当极力避免硬解析,尽可能使用软解析。


Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:

100.00

Redo NoWait %:

100.00

Buffer Hit %:

98.72

In-memory Sort %:

99.86

Library Hit %:

99.97

Soft Parse %:

99.92

Execute to Parse %:

89.09

Latch Hit %:

99.99

Parse CPU to Parse Elapsd %:

7.99

% Non-Parse CPU:

99.95

本节包含了Oracle关键指标的内存命中率及其它数据库实例操做的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio
Library Hit ratio也称Library Cache Hit ratio
Load Profile一节相同,这一节也没有所谓“正确”的值,而只能根据应用的特色判断是否合适。
在一个使用直接读执行大型并行查询的
DSS环境,20%Buffer Hit Ratio是能够接受的,而这个值对于一个OLTP系统是彻底不能接受的。
根据
Oracle的经验,对于OLTP系统,Buffer Hit Ratio理想应该在90%以上。

Buffer Nowait表示在内存得到数据的未等待比例。在缓冲区中获取Buffer的未等待比率
Buffer Nowait的这个值通常须要大于99%。不然可能存在争用,能够在后面的等待事件中进一步确认。


buffer hit表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个值自己更重要。
对于通常的OLTP系统,若是此值低于80%,应该给数据库分配更多的内存。
数据块在数据缓冲区中的命中率,一般应在95%以上。不然,小于95%,须要调整重要的参数,小于90%多是要加db_cache_size
一个高的命中率,不必定表明这个系统的性能是最优的,好比大量的非选择性的索引被频繁访问,就会形成命中率很高的假相大量的db file sequential read
可是一个比较低的命中率,通常就会对这个系统的性能产生影响,须要调整。命中率的突变,每每是一个很差的信息。
若是命中率忽然增大,能够检查top buffer get SQL,查看致使大量逻辑读的语句和索引,
若是命中率忽然减少,能够检查top physical reads SQL,检查产生大量物理读的语句,主要是那些没有使用索引或者索引被删除的。


Redo NoWait
表示在LOG缓冲区得到BUFFER的未等待比例。若是过低(可参考90%阀值),考虑增长LOG BUFFER
当redo buffer达到1M时,就须要写到redo log文件,因此通常当redo buffer设置超过1M,不太可能存在等待buffer空间分配的状况。
当前,通常设置为2M的redo buffer,对于内存总量来讲,应该不是一个太大的值。


library hit
表示OracleLibrary Cache中检索到一个解析过的SQLPL/SQL语句的比率,当应用程序调用SQL或存储过程时,
Oracle检查Library Cache肯定是否存在解析过的版本,若是存在,Oracle当即执行语句;若是不存在,Oracle解析此语句,并在Library Cache中为它分配共享SQL区。
低的
library hit ratio会致使过多的解析,增长CPU消耗,下降性能。
若是
library hit ratio低于90%,可能须要调大shared pool区。
STATEMENT在共享区的命中率,一般应该保持在95%以上,不然须要要考虑:加大共享池;使用绑定变量;修改cursor_sharing等参数。


Latch Hit
Latch是一种保护内存结构的锁,能够认为是SERVER进程获取访问内存数据结构的许可。
要确保
Latch Hit>99%,不然意味着Shared Pool latch争用,可能因为未共享的SQL,或者Library Cache过小,可以使用绑定变动或调大Shared Pool解决。
要确保>99%,不然存在严重的性能问题。当该值出现问题的时候,咱们能够借助后面的等待时间和latch分析来查找解决问题


Parse CPU to Parse Elapsd
解析实际运行时间/(解析实际运行时间+解析中等待资源时间)越高越好
计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。
即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。若是该比率为100%,意味着CPU等待时间为0,没有任何等待。


Non-Parse CPU 
SQL实际运行时间/(SQL实际运行时间+SQL解析时间)过低表示解析消耗时间过多
计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。若是这个值比较小,表示解析消耗的CPU时间过多。
与PARSE_CPU相比,若是TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工做是执行查询的工做,而不是分析查询的工做。


Execute to Parse
是语句执行与分析的比例,若是要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
计算公式为:Execute to Parse =100 * (1 - Parses/Executions)。
本例中,差很少每execution 5次须要一次parse。因此若是系统Parses > Executions,就可能出现该比率小于0的状况。
该值<0一般说明shared pool设置或者语句效率存在问题,形成反复解析,reparse可能较严重,或者是可能同snapshot有关,一般说明数据库性能存在问题。


In-memory Sort
在内存中排序的比率,若是太低说明有大量的排序在临时表空间中进行。
考虑调大
PGA(10g)若是低于95%,能够经过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决,
注意这两个参数设置做用的范围时不一样的,SORT_AREA_SIZE是针对每一个session设置的,PGA_AGGREGATE_TARGET则时针对全部的sesion的。


Soft Parse
软解析的百分比(softs/softs+hards),近似看成sql在共享区的命中率,过低则须要调整应用使用绑定变量
sql在共享区的命中率,小于<95%,须要考虑绑定,若是低于80%,那么就能够认为sql基本没有被重用。


Shared Pool Statistics

 

Begin

End

Memory Usage %:

47.19

47.50

% SQL with executions>1:

88.48

79.81

% Memory for SQL w/exec>1:

79.99

73.52


Memory Usage %对于一个已经运行一段时间的数据库来讲,共享池内存使用率,应该稳定在75%-90%
若是过小,说明
Shared Pool有浪费,而若是高于90,说明共享池中有争用,内存不足。
这个数字应该长时间稳定在75%~90%。若是这个百分比过低,代表共享池设置过大,带来额外的管理上的负担,从而在某些条件下会致使性能的降低。
若是这个百分率过高,会使共享池外部的组件老化,若是SQL语句被再次执行,这将使得SQL语句被硬解析。
在一个大小合适的系统中,共享池的使用率将处于75%到略低于90%的范围内.


SQL with executions>1:执行次数大于1sql比率,若是此值过小,说明须要在应用中更多使用绑定变量,避免过多SQL解析。
在一个趋向于循环运行的系统中,必须认真考虑这个数字。在这个循环系统中,在一天中相对于另外一部分时间的部分时间里执行了一组不一样的SQL语句。
在共享池中,在观察期间将有一组未被执行过的SQL语句,这仅仅是由于要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组,这个数字才会接近100%。


Memory for SQL w/exec>1:执行次数大于1SQL消耗内存的占比。
这是与不频繁使用的SQL语句相比,频繁使用的SQL语句消耗内存多少的一个度量。
这个数字将在整体上与% SQL with executions>1很是接近,除非有某些查询任务消耗的内存没有规律。
在稳定状态下,整体上会看见随着时间的推移大约有75%~85%的共享池被使用。若是Statspack报表的时间窗口足够大到覆盖全部的周期,
执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。能够指望它随观察之间的时间长度增大而增大。

 

小结:经过ORACLE的实例有效性统计数据,咱们能够得到大概的一个总体印象,然而咱们并不能由此来肯定数据运行的性能。当前性能问题的肯定,
咱们主要仍是依靠下面的等待事件来确认。咱们能够这样理解两部分的内容,hit统计帮助咱们发现和预测一些系统将要产生的性能问题,由此咱们
能够作到未雨绸缪。而wait事件,就是代表当前数据库已经出现了性能问题须要解决,因此是亡羊补牢的性质。

 

Top 5 Timed Events

Event

Waits

Time(s)

Avg Wait(ms)

% Total Call Time

Wait Class

CPU time

 

515

 

77.6

 

SQL*Net more data from client

27,319

64

2

9.7

Network

log file parallel write

5,497

47

9

7.1

System I/O

db file sequential read

7,900

35

4

5.3

User I/O

db file parallel write

4,806

34

7

5.1

System I/O


这是报告概要的最后一节,显示了系统中最严重的
5个等待,按所占等待时间的比例倒序列示。当咱们调优时,总但愿观察到最显著的效果,
所以应当从这里入手肯定咱们下一步作什么。
例如若是‘
buffer busy wait’是较严重的等待事件,咱们应当继续研究报告中Buffer WaitFile/Tablespace IO区的内容,
识别哪些文件致使了问题。若是最严重的等待事件是
I/O事件,咱们应当研究按物理读排序的SQL语句区以识别哪些语句在
执行大量
I/O,并研究TablespaceI/O区观察较慢响应时间的文件。若是有较高的LATCH等待,就须要察看详细的LATCH
统计识别哪些LATCH产生的问题。


一个性能良好的系统,
cpu time应该在top 5的前面,不然说明你的系统大部分时间都用在等待上。

在这里,log file parallel write是相对比较多的等待,占用了7%CPU时间。

一般,在没有问题的数据库中,CPU time老是列在第一个。

更多的等待事件,参见本报告 Wait Events一节。

 

RAC Statistics

 

Begin

End

Number of Instances:

2

2

Global Cache Load Profile

 

Per Second

Per Transaction

Global Cache blocks received:

4.16

3.51

Global Cache blocks served:

5.97

5.04

GCS/GES messages received:

408.47

344.95

GCS/GES messages sent:

258.03

217.90

DBWR Fusion writes:

0.05

0.05

Estd Interconnect traffic (KB)

211.16

 

Global Cache Efficiency Percentages (Target local+remote 100%)

Buffer access - local cache %:

98.60

Buffer access - remote cache %:

0.12

Buffer access - disk %:

1.28

Global Cache and Enqueue Services - Workload Characteristics

Avg global enqueue get time (ms):

0.1

Avg global cache cr block receive time (ms):

1.1

Avg global cache current block receive time (ms):

0.8

Avg global cache cr block build time (ms):

0.0

Avg global cache cr block send time (ms):

0.0

Global cache log flushes for cr blocks served %:

3.5

Avg global cache cr block flush time (ms):

3.9

Avg global cache current block pin time (ms):

0.0

Avg global cache current block send time (ms):

0.0

Global cache log flushes for current blocks served %:

0.4

Avg global cache current block flush time (ms):

3.0

Global Cache and Enqueue Services - Messaging Statistics

Avg message sent queue time (ms):

0.0

Avg message sent queue time on ksxp (ms):

0.3

Avg message received queue time (ms):

0.5

Avg GCS message process time (ms):

0.0

Avg GES message process time (ms):

0.0

% of direct sent messages:

14.40

% of indirect sent messages:

77.04

% of flow controlled messages:

8.56


Main Report


Wait Events Statistics

Back to Top

/* oracle等待事件是衡量oracle运行情况的重要依据及指示,等待事件分为两类:
空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序,= FALSE那么事件按等待的数量排序。
运行statspack期间必须session上设置TIMED_STATISTICS = TRUE,不然统计的数据将失真。
空闲等待事件是oracle正等待某种工做,在诊断和优化数据库时候,不用过多注意这部分事件,
非空闲等待事件专门针对oracle的活动,指数据库任务或应用程序运行过程当中发生的等待,
这些等待事件是咱们在调整数据库应该关注的

    对于常见的等待事件,说明以下:

1)    db file scattered read 文件分散读取
该事件一般与全表扫描或者fast full index scan有关。由于全表扫描是被放入内存中进行的进行的,一般状况下基于性能的考虑,有时候也多是分配不到足够长的连续内存空间,因此会将数据块分散(scattered)读入Buffer Cache中。该等待过大多是缺乏索引或者没有合适的索引(能够调整optimizer_index_cost_adj) 。这种状况也多是正常的,由于执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时,须要经过检查来肯定全表扫描是否必需的来调整。由于全表扫描被置于LRU(Least Recently Used,最近最少适用)列表的冷端(cold end),对于频繁访问的较小的数据表,能够选择把他们Cache 到内存中,以免反复读取。当这个等待事件比较显著时,能够结合v$session_longops 动态性能视图来进行诊断,该视图中记录了长时间(运行时间超过6 秒的)运行的事物,可能不少是全表扫描操做(无论怎样,这部分信息都是值得咱们注意的)。
关于参数OPTIMIZER_INDEX_COST_ADJ=n:该参数是一个百分比值,缺省值为100,能够理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST<FULL SCAN COST时,oracle会选择使用索引。在具体设置的时候,咱们能够根据具体的语句来调整该值。若是咱们但愿某个statement使用索引,而实际它确走全表扫描,能够对比这两种状况的执行计划不一样的COST,从而设置一个更合适的值。

2)    db file sequential read 文件顺序读取整代码,特别是表链接:该事件说明在单个数据块上大量等待,该值太高一般是因为表间链接顺序很糟糕(没有正确选择驱动行源),或者使用了非选择性索引。经过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),经过检查确保索引扫描是必须的,并确保多表链接的链接顺序来调整。

3)    buffer busy wait 缓冲区忙 增大DB_CACHE_SIZE,加速检查点,调整代码

当进程须要存取SGA中的buffer的时候,它会依次执行以下步骤的操做:

当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。该值不该该大于1%。当出 现等待问题时,能够检查缓冲等待统计部分(或V$WAITSTAT),肯定该等待发生在什么位置:

a)    若是等待是否位于段头(Segment Header)。这种状况代表段中的空闲列表(freelist)的块比较少。能够考虑增长空闲列表(freelist,对于Oracle8i DMT)或者增长freelist groups(在不少时候这个调整是立竿见影的(alter table tablename strorage(freelists 2)),在8.1.6以前,这个freelists参数不能动态修改;在8.1.6及之后版本,动态修改feelists须要设置COMPATIBLE至少为8.1.6)。也能够增长PCTUSED与PCTFREE之间距离PCTUSED-to-pctfree gap),其实就是说下降PCTUSED的值,尽快使块返回freelist列表被重用。若是支持自动段空间管理(ASSM),也能够使用ASSM模式,这是在ORALCE 920之后的版本中新增的特性。

b)    若是这一等待位于undo header,能够经过增长回滚段(rollback segment)来解决缓冲区的问题。

c)    若是等待位于undo block上,咱们须要增长提交的频率,使block能够尽快被重用;使用更大的回滚段;下降一致读所选择的表中数据的密度;增大DB_CACHE_SIZE。

d)    若是等待处于data block,代表出现了hot block,能够考虑以下方法解决: ①将频繁并发访问的表或数据移到另外一数据块或者进行更大范围的分布(能够增大pctfree值 ,扩大数据分布,减小竞争),以避开这个"热点"数据块。②也能够减少数据块的大小,从而减小一个数据块中的数据行数,下降数据块的热度,减少竞争;③检查对这些热块操做的SQL语句,优化语句。④增长hot block上的initrans值。但注意不要把initrans值设置的过于高了,一般设置为5就足够了。由于增长事务意味着要增长ITL事务槽,而每一个ITL事务槽将占用数据块中24个字节长度。默认状况下,每一个数据块或者索引块中是ITL槽是2个,在增长initrans的时候,能够考虑增大数据块所在的表的PCTFREE值,这样Oracle会利用PCTFREE部分的空间增长ITL slot数量,最大达到maxtrans指定。

e)    若是等待处于index block,应该考虑重建索引、分割索引或使用反向键索引。为了防止与数据块相关的缓冲忙等待,也能够使用较小的块,在这种状况下,单个块中的记录就较少,因此这个块就不是那么"繁忙"。或者能够设置更大的PCTFREE,使数据扩大物理分布,减小记录间的热点竞争。在执行DML (insert/update/ delete)时,Oracle向数据块中写入信息,对于多事务并发访问的数据表,关于ITL的竞争和等待可能出现,为了减小这个等待,能够增长initrans,使用多个ITL槽。在Oracle9i 中,能够使用ASSM这个新特性Oracle 使用位图来管理空间使用,减少争用。


当进程须要存取SGA中的buffer的时候,它会依次执行以下步骤的操做:
1.得到cache buffers chains latch,遍历那条buffer chain直到找到须要的buffer header
2.根据须要进行的操做类型(读或写),它须要在buffer header上得到一个共享或独占模式的buffer pin或者buffer lock
3.若进程得到buffer header pin,它会释放得到的cache buffers chains latch,而后执行对buffer block的操做
4.若进程没法得到buffer header pin,它就会在buffer busy waits事件上等待

进程之因此没法得到buffer header pin,是由于为了保证数据的一致性,同一时刻一个block只能被一个进程pin住进行存取,
所以当一个进程须要存取
buffer cache中一个被其余进程使用的block的时候,这个进程就会产生对该blockbuffer busy waits事件。

截至Oracle 9ibuffer busy waits事件的p1,p2,p3三个参数分别是file#,block#id,分别表示等待的buffer block所在的文件编号,
块编号和具体的等待缘由编号,到了
Oracle 10g,前两个参数没变,第3个参数变成了块类型编号,这一点能够经过查询v$event_name视图来进行验证:

Oracle 9i
SQLselect parameter1,parameter2,parameter3 from v$event_name where name='buffer busy waits'
PARAMETER1                  PARAMETER2                 PARAMETER3
------------------------ ------------------------ ------------------------
file#                             block#                          id
Oracle 10g
PARAMETER1                  PARAMETER2                 PARAMETER3
------------------------ ------------------------ ------------------------
file#                             block#                          class#


在诊断buffer busy waits事件的过程当中,获取以下信息会颇有用:
1.获取产生buffer busy waits事件的等待缘由编号,这能够经过查询该事件的p3参数值得到
2.获取产生此事件的SQL语句,能够经过以下的查询得到:
select sql_text from v$sql t1,v$session t2,v$session_wait t3
where t1.address=t2.sql_address and t1.hash_value=t2.sql_hash_value
and t2.sid=t3.sid and t3.event='buffer busy waits';
3.获取等待的块的类型以及所在的segment,能够经过以下查询得到:

select 'Segment Header' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and a.header_block=b.p2 and b.event='buffer busy waits'
union
select 'Freelist Groups' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and b.p2 between a.header_block+and (a.header_block+a.freelist_groups) and a.freelist_groups>and b.event='buffer busy waits'
union
select a.segment_type||' block' class,a.segment_type,a.segment_name,a.partition_name from dba_extents a,v$session_wait b
where a.file_id=b.p1 and b.p2 between a.block_id and a.block_id+a.blocks-and b.event='buffer busy waits' and not exists(select 1 from dba_segments where 
header_file=b.p1 and header_blockb.p2);


查询的第一部分:若是等待的块类型是segment header,那么能够直接拿buffer busy waits事件的p1p2参数去dba_segments视图中匹配header_fileheader_block字段便可找到等待的segment名称和segment类型,进行相应调整
查询的第二部分:若是等待的块类型是freelist groups,也能够在dba_segments视图中找出对应的segment名称和segment类型,注意这里的参数p2表示的freelist groups的位置是在segmentheader_block+1header_block+freelist groups组数之间,而且freelist groups组数大于1
查询的第三部分:若是等待的块类型是普通的数据块,那么能够用p1p2参数和dba_extents进行联合查询获得block所在的segment名称和segment类型

对于不一样的等待块类型,咱们采起不一样的处理办法:
1.data segment header
进程常常性的访问data segment header一般有两个缘由:获取或修改process freelists信息、扩展高水位标记,针对第一种状况,进程频繁访问process freelists信息致使freelist争用,咱们能够增大相应的segment对象的存储参数freelist或者freelist groups;若因为数据块频繁进出freelist而致使进程常常要修改freelist,则能够将pctfree值和pctused值设置较大的差距,从而避免数据块频繁进出freelist;对于第二种状况,因为该segment空间消耗很快,而设置的next extent太小,致使频繁扩展高水位标记,解决的办法是增大segment对象的存储参数next extent或者直接在建立表空间的时候设置extent size uniform
2.data block
某一或某些数据块被多个进程同时读写,成为热点块,能够经过以下这些办法来解决这个问题:
(1)下降程序的并发度,若是程序中使用了parallel查询,下降parallel degree,以避免多个parallel slave同时访问一样的数据对象而造成等待下降性能
(2)调整应用程序使之能读取较少的数据块就能获取所需的数据,减小buffer getsphysical reads
(3)减小同一个block中的记录数,使记录分布于更多的数据块中,这能够经过若干途径实现:能够调整segment对象的pctfree值,能够将segment重建到block size较小的表空间中,还能够用alter table minimize records_per_block语句减小每块中的记录数
(4)若热点块对象是相似自增id字段的索引,则能够将索引转换为反转索引,打散数据分布,分散热点块
3.undo segment header
undo segment header争用是由于系统中undo segment不够,须要增长足够的undo segment,根据undo segment管理方法,如果手工管理模式,须要修改rollback_segments初始化参数来增长rollback segment,如果自动管理模式,能够减少transactions_per_rollback_segment初始化参数的值来使oracle自动增多rollback segment的数量
4.undo block
undo block争用是因为应用程序中存在对数据的读和写同时进行,读进程须要到undo segment中去得到一致性数据,解决办法是错开应用程序修改数据和大量查询数据的时间

小结:buffer busy waits事件是oracle等待事件中比较复杂的一个,其造成缘由不少,须要根据p3参数对照Oracle提供的缘由代码表进行相应的诊断,10g之后则须要根据等待的block类型结合引发等待时间的具体SQL进行分析,采起相应的调整措施


4)    latch free:当闩锁丢失率高于0.5%时,须要调整这个问题。详细的咱们在后面的Latch Activity for DB部分说明。

latch是一种低级排队机制,用于保护SGA中共享内存结构。latch就像是一种快速地被获取和释放的内存锁。用于防止共享内存结构被多个用户同时访问。若是latch不可用,就会记录latch释放失败(latch free miss )。有两种与闩有关的类型:

  ■ 马上。

  ■ 能够等待。

  假如一个进程试图在马上模式下得到闩,而该闩已经被另一个进程所持有,若是该闩不能立可用的话,那么该进程就不会为得到该闩而等待。它将继续执行另外一个操做。

  大多数latch问题都与如下操做相关:

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

  一般咱们说,若是想设计一个失败的系统,不考虑绑定变量,这一个条件就够了,对于异构性强的系统,不使用绑定变量的后果是极其严重的。

  另外也有一些latch等待与bug有关,应当关注Metalink相关bug的公布及补丁的发布。当latch miss ratios大于0.5%时,就应当研究这一问题。

  Oracle的latch机制是竞争,其处理相似于网络里的CSMA/CD,全部用户进程争夺latch, 对于愿意等待类型(willing-to-wait)的latch,若是一个进程在第一次尝试中没有得到latch,那么它会等待而且再尝试一次,若是通过_spin_count次争夺不能得到latch, 而后该进程转入睡眠状态,持续一段指定长度的时间,而后再次醒来,按顺序重复之前的步骤.在8i/9i中默认值是_spin_count=2000。

  若是SQL语句不能调整,在8.1.6版本以上,Oracle提供了一个新的初始化参数: CURSOR_SHARING能够经过设置CURSOR_SHARING = force 在服务器端强制绑定变量。设置该参数可能会带来必定的反作用,对于Java的程序,有相关的bug,具体应用应该关注Metalink的bug公告。

 

***Latch 问题及可能解决办法 
------------------------------ 
* Library Cache and Shared Pool (未绑定变量---绑定变量,调整shared_pool_size) 
每当执行SQLPL/SQL存储过程,,函数和触发器时,这个Latch即被用到.Parse操做中此Latch也会被频繁使用
* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES参数
重作拷贝Latch用来从PGA向重作日志缓冲区拷贝重作记录
* Redo Allocation (最小化REDO生成,避免没必要要提交
Latch用来分配重作日志缓冲区中的空间,能够用NOLOGGING来减缓竞争
* Row Cache Objects (增大共享池
数据字典竞争.过分parsing. 
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS应增大或设为质数
"过热"数据块形成了内存缓冲链Latch竞争
* Cache Buffers Lru Chain (调整SQL,设置DB_BLOCK_LRU_LATCHES,或使用多个缓冲区池
扫描所有内存缓冲区块的LRU(最近最少使用)链时要用到内存缓冲区LRULatch.过小内存缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操做、DBWR速度跟不上工做负载等会引发此Latch竞争。

 

5)    Enqueue 队列是一种锁,保护一些共享资源,防止并发的DML操做。队列采用FIFO策略,注意latch并非采用的FIFO机制。比较常见的有3种类型的队列:ST队列,HW队列,TX4队列。
ST Enqueue的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法:1)将字典管理的表空间改成本地管理模式 2)预先分配分区或者将有问题的字典管理的表空间的next extent设置大一些。
HW Enqueue是用于segment的HWM的。当出现这种等待的时候,能够经过手工分配extents来解决。
TX4 Enqueue等待是最多见的等待状况。一般有3种状况会形成这种类型的等待:1)惟一索引中的重复索引。解决方法:commit或者rollback以释放队列。 2)对同一个位图索引段(bitmap index fragment)有多个update,由于一个bitmap index fragment可能包含了多个rowid,因此当多个用户更新时,可能一个用户会锁定该段,从而形成等待。解决方法同上。3)有多个用户同时对一个数据块做update,固然这些DML操做多是针对这个数据块的不一样的行,若是此时没有空闲的ITL槽,就会产生一个block-level锁。解决方法:增大表的initrans值使建立更多的ITL槽;或者增大表的pctfree值,这样oracle能够根据须要在pctfree的空间建立更多的ITL槽;使用smaller block size,这样每一个块中包含行就比较少,能够减少冲突发生的机会。

AWR报告分析--等待事件-队列.doc

6)    Free Buffer 释放缓冲区:这个等待事件代表系统正在等待内存中的可用空间,这说明当前Buffer 中已经没有Free 的内存空间。若是应用设计良好,SQL 书写规范,充分绑定变量,那这种等待可能说明Buffer Cache 设置的偏小,你可能须要增大DB_CACHE_SIZE。该等待也可能说明DBWR的写出速度不够,或者磁盘存在严重的竞争,能够须要考虑增长检查点、使用更多的DBWR 进程,或者增长物理磁盘的数量,分散负载,平衡IO。

7)    Log file single write:该事件仅与写日志文件头块相关,一般发生在增长新的组成员和增进序列号时。头块写单个进行,由于头块的部分信息是文件号,每一个文件不一样。更新日志文件头这个操做在后台完成,通常不多出现等待,无需太多关注。

8)    log file parallel write:从log buffer 写redo 记录到redo log 文件,主要指常规写操做(相对于log file sync)。若是你的Log group 存在多个组成员,当flush log buffer 时,写操做是并行的,这时候此等待事件可能出现。尽管这个写操做并行处理,直到全部I/O 操做完成该写操做才会完成(若是你的磁盘支持异步IO或者使用IO SLAVE,那么即便只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较能够用来衡量log file 的写入成本。一般称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中,尽可能不使用raid5,确保表空间不是处在热备模式下,确保redo log和data的数据文件位于不一样的磁盘中。

9)    log file sync:当一个用户提交或回滚数据时,LGWR将会话的redo记录从日志缓冲区填充到日志文件中,用户的进程必须等待这个填充工做完成。在每次提交时都出现,若是这个等待事件影响到数据库性能,那么就须要修改应用程序的提交频率, 为减小这个等待事件,须一次提交更多记录,或者将重作日志REDO LOG 文件访在不一样的物理磁盘上,提升I/O的性能。

当一个用户提交或回滚数据时,LGWR 将会话期的重作由日志缓冲器写入到重作日志中。日志文件同步过程必须等待这一过程成功完成。为了减小这种等待事件,能够尝试一次提交更多的记录(频繁的提交会带来更多的系统开销)。将重作日志置于较快的磁盘上,或者交替使用不一样物理磁盘上的重作日志,以下降归档对LGWR的影响。

  对于软RAID,通常来讲不要使用RAID 5,RAID5 对于频繁写入得系统会带来较大的性能损失,能够考虑使用文件系统直接输入/输出,或者使用裸设备(raw device),这样能够得到写入的性能提升。

10)  log buffer space:日志缓冲区写的速度快于LGWR写REDOFILE的速度,能够增大日志文件大小,增长日志缓冲区的大小,或者使用更快的磁盘来写数据。

 

当你将日志缓冲(log buffer)产生重作日志的速度比LGWR 的写出速度快,或者是当日志切换(log switch)太慢时,就会发生这种等待。这个等待出现时,一般代表redo log buffer 太小,为解决这个问题,能够考虑增大日志文件的大小,或者增长日志缓冲器的大小。

  另一个可能的缘由是磁盘I/O 存在瓶颈,能够考虑使用写入速度更快的磁盘。在容许的条件下设置能够考虑使用裸设备来存放日志文件,提升写入效率。在通常的系统中,最低的标准是,不要把日志文件和数据文件存放在一块儿,由于一般日志文件只写不读,分离存放能够得到性能提高。

 

11)  logfile switch:一般是由于归档速度不够快。表示全部的提交(commit)的请求都须要等待"日志文件切换"的完成。Log file Switch 主要包含两个子事件:
log file switch (archiving needed) 这个等待事件出现时一般是由于日志组循环写满之后,第一个日志归档还没有完成,出现该等待。出现该等待,可能表示io 存在问题。解决办法:①能够考虑增大日志文件和增长日志组;②移动归档文件到快速磁盘;③调整log_archive_max_processes。
log file switch (checkpoint incomplete) 当日志组都写完之后,LGWR 试图写第一个log file,若是这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成),该等待事件出现。该等待事件一般表示你的DBWR 写出速度太慢或者IO 存在问题。为解决该问题,你可能须要考虑增长额外的DBWR 或者增长你的日志组或日志文件大小,或者也能够考虑增长checkpoint的频率。

12)  DB File Parallel Write:文件被DBWR并行写时发生。解决办法:改善IO性能。

处理此事件时,须要注意

1db file parallel write事件只属于DBWR进程。

2)缓慢的DBWR可能影响前台进程。

3)大量的db file parallel write等待时间极可能是I/O问题引发的。(在确认os支持异步io的前提下,你能够在系统中检查disk_asynch_io参数,保证为TRUE。能够经过设置db_writer_processes来提升DBWR进程数量,固然前提是不要超过cpu的数量。)
     DBWR进程执行通过SGA的全部数据库写入,当开始写入时,DBWR进程编译一组脏块(dirty block),而且将系统写入调用发布到操做系统。DBWR进程查找在各个时间内写入的块,包括每隔3秒的一次查找,当前台进程提交以清除缓冲区中的内容时:在检查点处查找,当知足_DB_LARGE_DIRTY_QUEUE_DB_BLOCK_MAX_DIRTY_TARGETFAST_START_MTTR_TARGET阀值时,等等。
    虽然用户会话历来没有经历过db file parallel write等待事件,但这并不意味着它们不会受到这种事件的影响。缓慢的DBWR写入性能能够形成前台会话在write complete waitsfree buffer waits事件上等待。DBWR写入性能可能受到以下方面的影响:I/O操做的类型(同步或异步)、存储设备(裸设备或成熟的文件系统)、数据库布局和I/O子系统配置。须要查看的关键数据库统计是当db file parallel writefree buffer waitswrite complete waits等待事件互相关联时,系统范围内的TIME_WAITEDAVERAGE_WAIT
    若是db file parallel write平均等待时间大于10cs(或者100ms),则一般代表缓慢的I/O吞吐量。能够经过不少方法来改善平均等待时间。主要的方法是使用正确类型的I/O操做。若是数据文件位于裸设备(raw device)上,而且平台支持异步I/O,就应该使用异步写入。可是,若是数据库位于文件系统上,则应该使用同步写入和直接I/O(这是操做系统直接I/O)。除了确保正在使用正确类型的I/O操做,还应该检查你的数据库布局并使用常见的命令监控来自操做系统的I/O吞吐量。例如sar -diostat -dxnC
    db file parallel write平均等待时间高而且系统繁忙时,用户会话可能开始在free buffer waits事件上等待。这是由于DBWR进程不能知足释放缓冲区的需求。若是free buffer waits事件的TIME_WAITED高,则应该在高速缓存中增长缓冲区数量以前说明DBWR I/O吞吐量的问题。
    db file parallel write平均等待时间的另外一个反响是在write complete waits等待事件上的高TIME_WAITED。前台进程不容许修改正在传输到磁盘的块。换句话说,也就是位于DBWR批量写入中的块。前台的会话在write complete waits等待事件上等待。所以,write complete waits事件的出现,必定标志着缓慢的DBWR进程,能够经过改进DBWR I/O吞吐量修正这种延迟。

13)  DB File Single Write:当文件头或别的单独块被写入时发生,这一等待直到全部的I/O调用完成。解决办法:改善IO性能。

14)  DB FILE Scattered Read:当扫描整个段来根据初始化参数db_file_multiblock_read_count读取多个块时发生,由于数据可能分散在不一样的部分,这与分条或分段)相关,所以一般须要多个分散的读来读取全部的数据。等待时间是完成全部I/O调用的时间。解决办法:改善IO性能。

这种状况一般显示与全表扫描相关的等待。
当数据库进行全表扫时,基于性能的考虑,数据会分散(scattered)读入Buffer Cache。若是这个等待事件比较显著,可能说明对于某些全表扫描的表,没有建立索引或者没有建立合适的索引,咱们可能须要检查这些数据表已肯定是否进行了正确的设置。

然而这个等待事件不必定意味着性能低下,在某些条件下Oracle会主动使用全表扫描来替换索引扫描以提升性能,这和访问的数据量有关,在CBOOracle会进行更为智能的选择,在RBOOracle更倾向于使用索引。

由于全表扫描被置于LRULeast Recently Used,最近最少适用)列表的冷端(cold end),对于频繁访问的较小的数据表,能够选择把他们Cache到内存中,以免反复读取。

当这个等待事件比较显著时,能够结合v$session_longops动态性能视图来进行诊断,该视图中记录了长时间(运行时间超过6秒的)运行的事物,可能不少是全表扫描操做(无论怎样,这部分信息都是值得咱们注意的)。

15)  DB FILE Sequential Read:当前台进程对数据文件进行常规读时发生,包括索引查找和别的非整段扫描以及数据文件块丢弃等待。等待时间是完成全部I/O调用的时间。解决办法:改善IO性能。

若是这个等待事件比较显著,可能表示在多表链接中,表的链接顺序存在问题,没有正确地使用驱动表;或者可能索引的使用存在问题,并不是索引老是最好的选择。在大多数状况下,经过索引能够更为快速地获取记录,因此对于编码规范、调整良好的数据库,这个等待事件很大一般是正常的。有时候这个等待太高和存储分布不连续、连续数据块中部分被缓存有关,特别对于DML频繁的数据表,数据以及存储空间的不连续可能致使过量的单块读,按期的数据整理和空间回收有时候是必须的。

须要注意在不少状况下,使用索引并非最佳的选择,好比读取较大表中大量的数据,全表扫描可能会明显快于索引扫描,因此在开发中就应该注意,对于这样的查询应该进行避免使用索引扫描。

16)  Direct Path Read:通常直接路径读取是指将数据块直接读入PGA中。通常用于排序、并行查询和read ahead操做。这个等待多是因为I/O形成的。使用异步I/O模式或者限制排序在磁盘上,可能会下降这里的等待时间。

与直接读取相关联的等待事件。当ORACLE将数据块直接读入会话的PGA(进程全局区)中,同时绕过SGA(系统全局区)。PGA中的数据并不和其余的会话共享。即代表,读入的这部分数据该会话独自使用,不放于共享的SGA中。

在排序操做(order by/group by/union/distinct/rollup/合并链接)时,因为PGA中的SORT_AREA_SIZE空间不足,形成须要使用临时表空间来保存中间结果,当从临时表空间读入排序结果时,产生direct path read等待事件。

使用HASH链接的SQL语句,将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配SQL谓词的行,临时表空间中的散列分区被读回到内存中(目的是为了查明匹配SQL谓词的行)ORALCE会话在direct path read等待事件上等待。

使用并行扫描的SQL语句也会影响系统范围的direct path read等待事件。在并行执行过程当中,direct path read等待事件与从属查询有关,而与父查询无关,运行父查询的会话基本上会在PX Deq:Execute Reply上等待,从属查询会产生direct path read等待事件。

直接读取可能按照同步或异步的方式执行,取决于平台和初始化参数disk_asynch_io参数的值。使用异步I/O时,系统范围的等待的事件的统计可能不许确,会形成误导做用。

17)  direct path write:直接路径写该等待发生在,系统等待确认全部未完成的异步I/O 都已写入磁盘。对于这一写入等待,咱们应该找到I/O 操做最为频繁的数据文件(若是有过多的排序操做,颇有可能就是临时文件),分散负载,加快其写入操做。若是系统存在过多的磁盘排序,会致使临时表空间操做频繁,对于这种状况,能够考虑使用Local管理表空间,分红多个小文件,写入不一样磁盘或者裸设备。

DSS系统中,存在大量的direct path read是很正常的,可是在OLTP系统中,一般显著的直接路径读(direct path read)都意味着系统应用存在问题,从而致使大量的磁盘排序读取操做。

直接路径写(direct paht write)一般发生在Oracle直接从PGA写数据到数据文件或临时文件,这个写操做能够绕过SGA

这类写入操做一般在如下状况被使用:
·直接路径加载;
·并行DML操做;
·磁盘排序;
·对未缓存的LOB段的写入,随后会记录为direct path write(lob)等待。

最为常见的直接路径写,多数由于磁盘排序致使。对于这一写入等待,咱们应该找到I/O操做最为频繁的数据文件(若是有过多的排序操做,颇有可能就是临时文件),分散负载,加快其写入操做。

18)  control file parallel write:当server 进程更新全部控制文件时,这个事件可能出现。若是等待很短,能够不用考虑。若是等待时间较长,检查存放控制文件的物理磁盘I/O 是否存在瓶颈。
多个控制文件是彻底相同的拷贝,用于镜像以提升安全性。对于业务系统,多个控制文件应该存放在不一样的磁盘上,通常来讲三个是足够的,若是只有两个物理硬盘,那么两个控制文件也是能够接受的。在同一个磁盘上保存多个控制文件是不具有实际意义的。减小这个等待,能够考虑以下方法:①减小控制文件的个数(在确保安全的前提下)。②若是系统支持,使用异步IO。③转移控制文件到IO 负担轻的物理磁盘。

19)  control file sequential read 
control file single write 
:控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时,这两个事件会出现。若是等待比较明显,检查单个控制文件,看存放位置是否存在I/O 瓶颈。

20)   library cache pin

该事件一般是发生在先有会话在运行PL/SQL,VIEW,TYPES等object时,又有另外的会话执行从新编译这些object,即先给对象加上了一个共享锁,而后又给它加排它锁,这样在加排它锁的会话上就会出现这个等待。P1,P2可与x$kglpn和x$kglob表相关 
X$KGLOB (Kernel Generic Library Cache Manager Object) 
X$KGLPN (Kernel Generic Library Cache Manager Object Pins) 
-- 查询X$KGLOB,可找到相关的object,其SQL语句以下 
(即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连) 
select kglnaown,kglnaobj from X$KGLOB 
where KGLHDADR =(select p1raw from v$session_wait 
where event='library cache pin') 
-- 查出引发该等待事件的阻塞者的sid 
select sid from x$kglpn , v$session 
where KGLPNHDL in 
(select p1raw from v$session_wait 
where wait_time=0 and event like 'library cache pin%') 
and KGLPNMOD <> 0 
and v$session.saddr=x$kglpn.kglpnuse 
-- 查出阻塞者正执行的SQL语句 
select sid,sql_text 
from v$session, v$sqlarea 
where v$session.sql_address=v$sqlarea.address 
and sid=<阻塞者的sid> 
这样,就可找到"library cache pin"等待的根源,从而解决由此引发的性能问题。

21)  library cache lock 
该事件一般是因为执行多个DDL操做致使的,即在library cache object上添加一个排它锁后,又从另外一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可经过到基表x$kgllk中查找其对应的对象。 
-- 查询引发该等待事件的阻塞者的sid、会话用户、锁住的对象 
select b.sid,a.user_name,a.kglnaobj 
from x$kgllk a , v$session b 
where a.kgllkhdl in 
(select p1raw from v$session_wait 
where wait_time=0 and event = 'library cache lock') 
and a.kgllkmod <> 0 
and b.saddr=a.kgllkuse 
固然也能够直接从v$locked_objects中查看,但没有上面语句直观根据sid能够到v$process中查出pid,而后将其kill或者其它处理。

22)   

对于常见的一些IDLE wait事件举例:

dispatcher timer                  

lock element cleanup              

Null event                        

parallel query dequeue wait       

parallel query idle wait - Slaves 

pipe get                          

PL/SQL lock timer                 

pmon timer- pmon                  

rdbms ipc message                 

slave wait                        

smon timer                        

SQL*Net break/reset to client     

SQL*Net message from client       

SQL*Net message to client         

SQL*Net more data to client       

virtual circuit status            

client message                    

SQL*Net message from client  

下面是关于这里的常见的等待事件和解决方法的一个快速预览

等待事件

通常解决方法

Sequential Read

调整相关的索引和选择合适的驱动行源

Scattered Read

代表出现不少全表扫描。优化code,cache小表到内存中。

Free Buffer

增大DB_CACHE_SIZE,增大checkpoint的频率,优化代码

Buffer Busy Segment header

增长freelist或者freelistgroups

Buffer Busy Data block

隔离热块;使用反转索引;使用更小的块;增大表的initrans

Buffer Busy Undo header

增长回滚段的数量或者大小

Buffer Busy Undo block

Commit more;增长回滚段的数量或者大小

Latch Free

检查具体的等待latch类型,解决方法参考后面介绍

Enqueue–ST

使用本地管理的表空间或者增长预分配的盘区大小

Enqueue–HW

在HWM之上预先分配盘区

Enqueue–TX4

在表或者索引上增大initrans的值或者使用更小的块

Log Buffer Space

增大LOG_BUFFER,改善I/O

Log File Switch

增长或者增大日志文件

Log file sync

减少提交的频率;使用更快的I/O;或者使用裸设备

Write complete waits

增长DBWR;提升CKPT的频率;

 

Time Model Statistics

  • Total time in database user-calls (DB Time): 663s
  • Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
  • Ordered by % or DB time desc, Statistic name

Statistic Name

Time (s)

% of DB Time

DB CPU

514.50

77.61

sql execute elapsed time

482.27

72.74

parse time elapsed

3.76

0.57

PL/SQL execution elapsed time

0.50

0.08

hard parse elapsed time

0.34

0.05

connection management call elapsed time

0.08

0.01

hard parse (sharing criteria) elapsed time

0.00

0.00

repeated bind elapsed time

0.00

0.00

PL/SQL compilation elapsed time

0.00

0.00

failed parse elapsed time

0.00

0.00

DB time

662.97

 

background elapsed time

185.19

 

background cpu time

67.48

 

此节显示了各类类型的数据库处理任务所占用的CPU时间。

DB time=报表头部显示的db time=cpu time + all of nonidle wait event time

 

Back to Wait Events Statistics 
Back to Top

Wait Class 等待事件的类型

  • s - second
  • cs - centisecond - 100th of a second
  • ms - millisecond - 1000th of a second
  • us - microsecond - 1000000th of a second
  • ordered by wait time desc, waits desc

查询Oracle 10gR1提供的12个等待事件类:

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

Wait Class

Waits

%Time -outs

Total Wait Time (s)

Avg wait (ms)

Waits /txn

User I/O

66,837

0.00

120

2

11.94

System I/O

28,295

0.00

93

3

5.05

Network

1,571,450

0.00

66

0

280.72

Cluster

210,548

0.00

29

0

37.61

Other

81,783

71.82

28

0

14.61

Application

333,155

0.00

16

0

59.51

Concurrency

5,182

0.04

5

1

0.93

Commit

919

0.00

4

4

0.16

Configuration

25,427

99.46

1

0

4.54

Back to Wait Events Statistics 
Back to Top

Wait Events 现实非空闲等待事件 后面是空闲等待事件

  • s - second
  • cs - centisecond - 100th of a second
  • ms - millisecond - 1000th of a second
  • us - microsecond - 1000000th of a second
  • ordered by wait time desc, waits desc (idle events last)

 

1)查询全部等待事件及其属性:

select event#, name, parameter1, parameter2, parameter3 from v$event_name order by name;

 

2)查询Oracle 10gR1提供的12个等待事件类:

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

 

wait_event.doc

下面显示的内容可能来自下面几个视图)

V$EVENT_NAME视图包含全部为数据库实例定义的等待事件。

V$SYSTEM_EVENT视图显示自从实例启动后,全部Oracle会话遇到的全部等待事件的总计统计。

V$SESSION_EVENT视图包含当前链接到实例的全部会话的总计等待事件统计。该视图包含了V$SYSTEM_EVENT视图中出现的全部列。它记录会话中每个等待事件的总等待次数、已等待时间和最大等待时间。SID列标识出独立的会话。每一个会话中每一个事件的最大等待时间在MAX_WAIT列中追踪。经过用SID列将V$SESSION_EVENT视图和V$SESSION视图结合起来,可获得有关会话和用户的更多信息。

V$SESSION_WAIT视图提供关于每一个会话正在等待的事件或资源的详细信息。该视图在任何给定时间,只包含每一个会话的一行活动的或不活动的信息。

自从OWIOracle 7.0.12中引入后,就具备下来4V$视图:

·           V$EVENT_NAME

·           V$SESSION_WAIT

·           V$SESSION_EVENT

·           V$SYSTEM_EVENT

除了这些等待事件视图以外,Oracle 10gR1中引入了下列新视图以从多个角度显示等待信息:

·           V$SYSTEM_WAIT_CLASS

·           V$SESSION_WAIT_CLASS

·           V$SESSION_WAIT_HISTORY

·           V$EVENT_HISTOGRAM

·           V$ACTIVE_SESSION_HISTORY

然而,V$SESSION_WAITV$SESSION_WAITV$SESSION_WAIT仍然是3个重要的视图,它们提供了不一样粒度级的等待事件统计和计时信息。三者的关系以下:

V$SESSION_WAIT ? V$SESSION_EVENT ? V$SYSTEM_EVENT

 

Event

Waits

%Time -outs

Total Wait Time (s)

Avg wait (ms)

Waits /txn

SQL*Net more data from client

27,319

0.00

64

2

4.88

log file parallel write

5,497

0.00

47

9

0.98

db file sequential read

7,900

0.00

35

4

1.41

db file parallel write

4,806

0.00

34

7

0.86

db file scattered read

10,310

0.00

31

3

1.84

direct path write

42,724

0.00

30

1

7.63

reliable message

355

2.82

18

49

0.06

SQL*Net break/reset to client

333,084

0.00

16

0

59.50

db file parallel read

3,732

0.00

13

4

0.67

gc current multi block request

175,710

0.00

10

0

31.39

control file sequential read

15,974

0.00

10

1

2.85

direct path read temp

1,873

0.00

9

5

0.33

gc cr multi block request

20,877

0.00

8

0

3.73

log file sync

919

0.00

4

4

0.16

gc cr block busy

526

0.00

3

6

0.09

enq: FB - contention

10,384

0.00

3

0

1.85

DFS lock handle

3,517

0.00

3

1

0.63

control file parallel write

1,946

0.00

3

1

0.35

gc current block 2-way

4,165

0.00

2

0

0.74

library cache lock

432

0.00

2

4

0.08

name-service call wait

22

0.00

2

76

0.00

row cache lock

3,894

0.00

2

0

0.70

gcs log flush sync

1,259

42.02

2

1

0.22

os thread startup

18

5.56

2

89

0.00

gc cr block 2-way

3,671

0.00

2

0

0.66

gc current block busy

113

0.00

1

12

0.02

SQL*Net message to client

1,544,115

0.00

1

0

275.83

gc buffer busy

15

6.67

1

70

0.00

gc cr disk read

3,272

0.00

1

0

0.58

direct path write temp

159

0.00

1

5

0.03

gc current grant busy

898

0.00

1

1

0.16

log file switch completion

29

0.00

1

17

0.01

CGS wait for IPC msg

48,739

99.87

0

0

8.71

gc current grant 2-way

1,142

0.00

0

0

0.20

kjbdrmcvtq lmon drm quiesce: ping completion

9

0.00

0

19

0.00

enq: US - contention

567

0.00

0

0

0.10

direct path read

138

0.00

0

1

0.02

enq: WF - contention

14

0.00

0

9

0.00

ksxr poll remote instances

13,291

58.45

0

0

2.37

library cache pin

211

0.00

0

1

0.04

ges global resource directory to be frozen

9

100.00

0

10

0.00

wait for scn ack

583

0.00

0

0

0.10

log file sequential read

36

0.00

0

2

0.01

undo segment extension

25,342

99.79

0

0

4.53

rdbms ipc reply

279

0.00

0

0

0.05

ktfbtgex

6

100.00

0

10

0.00

enq: HW - contention

44

0.00

0

1

0.01

gc cr grant 2-way

158

0.00

0

0

0.03

enq: TX - index contention

1

0.00

0

34

0.00

enq: CF - contention

64

0.00

0

1

0.01

PX Deq: Signal ACK

37

21.62

0

1

0.01

latch free

3

0.00

0

10

0.00

buffer busy waits

625

0.16

0

0

0.11

KJC: Wait for msg sends to complete

154

0.00

0

0

0.03

log buffer space

11

0.00

0

2

0.00

enq: PS - contention

46

0.00

0

1

0.01

enq: TM - contention

70

0.00

0

0

0.01

IPC send completion sync

40

100.00

0

0

0.01

PX Deq: reap credit

1,544

99.81

0

0

0.28

log file single write

36

0.00

0

0

0.01

enq: TT - contention

46

0.00

0

0

0.01

enq: TD - KTF dump entries

12

0.00

0

1

0.00

read by other session

1

0.00

0

12

0.00

LGWR wait for redo copy

540

0.00

0

0

0.10

PX Deq Credit: send blkd

17

5.88

0

0

0.00

enq: TA - contention

14

0.00

0

0

0.00

latch: ges resource hash list

44

0.00

0

0

0.01

enq: PI - contention

8

0.00

0

0

0.00

write complete waits

1

0.00

0

2

0.00

enq: DR - contention

3

0.00

0

0

0.00

enq: MW - contention

3

0.00

0

0

0.00

enq: TS - contention

3

0.00

0

0

0.00

PX qref latch

150

100.00

0

0

0.03

PX qref latch

在并行执行的状况下偶然会发现PX qref latch等待事件,当系统高峰期同时采用了高并发的状况下最容易出现。看来要进行特殊照顾了。

概念和原理
在并行执行环境中,query slaves query coordinator之间是经过队列交换数据和信息的。PX qref latch 是用来保护这些队列的。
PX qref latch 等待事件的出现通常代表信息的发送比接受快,这时须要调整buffer size(能够经过parallel_execution_message_size参数调整)。
可是有些状况下也是难以免发生这种状况的,好比consumer须要长时间的等待数据的处理,缘由在于须要返回大批量的数据包,这种状况下很正常。

调整和措施
当系统的负载比较高时,须要把并行度下降;若是使用的是默认并行度,能够经过减少parallel_thread_per_cpu参数的值来达到效果。
DEFAULT degree = PARALLEL_THREADS_PER_CPU * #CPU's

优化parallel_execution_message_size参数
Tuning parallel_execution_message_size is a tradeoff between
performance and memory. For parallel query, the connection
topology between slaves and QC requires (n^2 + 2n) connections
(where n is the DOP not the actual number of slaves) at maximum. 
If each connection has 3 buffers associated with it then you can
very quickly get into high memory consumption on large machines 
doing high DOP queries

enq: MD - contention

2

0.00

0

0

0.00

latch: KCL gc element parent latch

11

0.00

0

0

0.00

enq: JS - job run lock - synchronize

1

0.00

0

1

0.00

SQL*Net more data to client

16

0.00

0

0

0.00

latch: cache buffers lru chain

1

0.00

0

0

0.00

enq: UL - contention

1

0.00

0

0

0.00

gc current split

1

0.00

0

0

0.00

enq: AF - task serialization

1

0.00

0

0

0.00

latch: object queue header operation

3

0.00

0

0

0.00

latch: cache buffers chains

1

0.00

0

0

0.00

latch: enqueue hash chains

2

0.00

0

0

0.00

SQL*Net message from client

1,544,113

0.00

12,626

8

275.83

gcs remote message

634,884

98.64

9,203

14

113.41

DIAG idle wait

23,628

0.00

4,616

195

4.22

ges remote message

149,591

93.45

4,612

31

26.72

Streams AQ: qmn slave idle wait

167

0.00

4,611

27611

0.03

Streams AQ: qmn coordinator idle wait

351

47.86

4,611

13137

0.06

Streams AQ: waiting for messages in the queue

488

100.00

4,605

9436

0.09

virtual circuit status

157

100.00

4,596

29272

0.03

PX Idle Wait

1,072

97.11

2,581

2407

0.19

jobq slave wait

145

97.93

420

2896

0.03

Streams AQ: waiting for time management or cleanup tasks

1

100.00

270

269747

0.00

PX Deq: Parse Reply

40

40.00

0

3

0.01

PX Deq: Execution Msg

121

26.45

0

0

0.02

PX Deq: Join ACK

38

42.11

0

1

0.01

PX Deq: Execute Reply

34

32.35

0

0

0.01

PX Deq: Msg Fragment

16

0.00

0

0

0.00

Streams AQ: RAC qmn coordinator idle wait

351

100.00

0

0

0.06

class slave wait

2

0.00

0

0

0.00

db file scattered read等待事件是当SESSION等待multi-block I/O时发生的,经过是因为full table scans index fast full scans。发生过多读操做的Segments能够在“Segments by Physical Reads” “SQL ordered by Reads”节中识别(在其它版本的报告中,多是别的名称)。若是在OLTP应用中,不该该有过多的全扫描操做,而应使用选择性好的索引操做。

DB file sequential read等待意味着发生顺序I/O读等待(一般是单块读取到连续的内存区域中),若是这个等待很是严重,应该使用上一段的方法肯定执行读操做的热点SEGMENT,而后经过对大表进行分区以减小I/O量,或者优化执行计划(经过使用存储大纲或执行数据分析)以免单块读操做引发的sequential read等待。经过在批量应用中,DB file sequential read是很影响性能的事件,老是应当设法避免。

Log File Parallel Write 事件是在等待LGWR进程将REDO记录从LOG 缓冲区写到联机日志文件时发生的。虽然写操做多是并发的,但LGWR须要等待最后的I/O写到磁盘上才能认为并行写的完成,所以等待时间依赖于OS完成全部请求的时间。若是这个等待比较严重,能够经过将LOG文件移到更快的磁盘上或者条带化磁盘(减小争用)而下降这个等待。

Buffer Busy Waits事件是在一个SESSION须要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个缘由是:1)另外一个SESSION正在将数据块读进BUFFER2)另外一个SESSION正在以排它模式占用着这块被请求的BUFFER。能够在“Segments by Buffer Busy Waits”一节中找出发生这种等待的SEGMENT,而后经过使用reverse-key indexes并对热表进行分区而减小这种等待事件。

Log File Sync事件,当用户SESSION执行事务操做(COMMITROLLBACK等)后,会通知 LGWR进程将所须要的全部REDO信息从LOG BUFFER写到LOG文件,在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。减小此等待的方法写Log File Parallel Write事件的处理。

Enqueue Waits是串行访问本地资源的本锁,代表正在等待一个被其它SESSION(一个或多个)以排它模式锁住的资源。减小这种等待的方法依赖于生产等待的锁类型。致使Enqueue等待的主要锁类型有三种:TX(事务锁), TM DML锁)ST空间管理锁)。

Back to Wait Events Statistics 
Back to Top

Background Wait Events

  • ordered by wait time desc, waits desc (idle events last)


Event

Waits

%Time -outs

Total Wait Time (s)

Avg wait (ms)

Waits /txn

log file parallel write

5,497

0.00

47

9

0.98

db file parallel write

4,806

0.00

34

7

0.86

events in waitclass Other

69,002

83.25

22

0

12.33

control file sequential read

9,323

0.00

7

1

1.67

control file parallel write

1,946

0.00

3

1

0.35

os thread startup

18

5.56

2

89

0.00

direct path read

138

0.00

0

1

0.02

db file sequential read

21

0.00

0

5

0.00

direct path write

138

0.00

0

0

0.02

log file sequential read

36

0.00

0

2

0.01

gc cr block 2-way

96

0.00

0

0

0.02

gc current block 2-way

78

0.00

0

0

0.01

log buffer space

11

0.00

0

2

0.00

row cache lock

59

0.00

0

0

0.01

log file single write

36

0.00

0

0

0.01

buffer busy waits

151

0.66

0

0

0.03

gc current grant busy

29

0.00

0

0

0.01

library cache lock

4

0.00

0

1

0.00

enq: TM - contention

10

0.00

0

0

0.00

gc current grant 2-way

8

0.00

0

0

0.00

gc cr multi block request

7

0.00

0

0

0.00

gc cr grant 2-way

5

0.00

0

0

0.00

rdbms ipc message

97,288

73.77

50,194

516

17.38

gcs remote message

634,886

98.64

9,203

14

113.41

DIAG idle wait

23,628

0.00

4,616

195

4.22

pmon timer

1,621

100.00

4,615

2847

0.29

ges remote message

149,591

93.45

4,612

31

26.72

Streams AQ: qmn slave idle wait

167

0.00

4,611

27611

0.03

Streams AQ: qmn coordinator idle wait

351

47.86

4,611

13137

0.06

smon timer

277

6.50

4,531

16356

0.05

Streams AQ: waiting for time management or cleanup tasks

1

100.00

270

269747

0.00

PX Deq: Parse Reply

40

40.00

0

3

0.01

PX Deq: Join ACK

38

42.11

0

1

0.01

PX Deq: Execute Reply

34

32.35

0

0

0.01

Streams AQ: RAC qmn coordinator idle wait

351

100.00

0

0

0.06

Back to Wait Events Statistics 
Back to Top

Operating System Statistics

Statistic

Total

NUM_LCPUS

0

NUM_VCPUS

0

AVG_BUSY_TIME

101,442

AVG_IDLE_TIME

371,241

AVG_IOWAIT_TIME

5,460

AVG_SYS_TIME

25,795

AVG_USER_TIME

75,510

BUSY_TIME

812,644

IDLE_TIME

2,971,077

IOWAIT_TIME

44,794

SYS_TIME

207,429

USER_TIME

605,215

LOAD

0

OS_CPU_WAIT_TIME

854,100

RSRC_MGR_CPU_WAIT_TIME

0

PHYSICAL_MEMORY_BYTES

8,589,934,592

NUM_CPUS

8

NUM_CPU_CORES

4

NUM_LCPUS                  若是显示0,是由于没有设置LPARS

NUM_VCPUS                    同上。

AVG_BUSY_TIME           BUSY_TIME / NUM_CPUS

AVG_IDLE_TIME             IDLE_TIME / NUM_CPUS

AVG_IOWAIT_TIME              IOWAIT_TIME / NUM_CPUS

AVG_SYS_TIME               SYS_TIME / NUM_CPUS

AVG_USER_TIME            USER_TIME / NUM_CPUSar o

BUSY_TIME                      time equiv of %usr+%sys in sar output

IDLE_TIME                        time equiv of %idle in sar

IOWAIT_TIME                  time equiv of %wio in sar

SYS_TIME                          time equiv of %sys in sar

USER_TIME                       time equiv of %usr in sar

LOAD                                  未知

OS_CPU_WAIT_TIME      supposedly time waiting on run queues

RSRC_MGR_CPU_WAIT_TIME   time waited coz of resource manager

PHYSICAL_MEMORY_BYTES    total memory in use supposedly

NUM_CPUS                       number of CPUs reported by OS 操做系统CPU

NUM_CPU_CORES          number of CPU sockets on motherboard 主板上CPU插槽数

总的elapsed time也能够用以公式计算:

BUSY_TIME + IDLE_TIME + IOWAIT TIME

或:SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME

 (由于BUSY_TIME = SYS_TIME+USER_TIME

Back to Wait Events Statistics 
Back to Top

Service Statistics

  • ordered by DB Time

Service Name

DB Time (s)

DB CPU (s)

Physical Reads

Logical Reads

ICCI

608.10

496.60

315,849

16,550,972

SYS$USERS

54.70

17.80

6,539

58,929

ICCIXDB

0.00

0.00

0

0

SYS$BACKGROUND

0.00

0.00

282

38,990

Back to Wait Events Statistics 
Back to Top

Service Wait Class Stats

  • Wait Class info for services in the Service Statistics section.
  • Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network
  • Time Waited (Wt Time) in centisecond (100th of a second)

Service Name

User I/O Total Wts

User I/O Wt Time

Concurcy Total Wts

Concurcy Wt Time

Admin Total Wts

Admin Wt Time

Network Total Wts

Network Wt Time

ICCI

59826

8640

4621

338

0

0

1564059

6552

SYS$USERS

6567

3238

231

11

0

0

7323

3

SYS$BACKGROUND

443

115

330

168

0

0

0

0

Back to Wait Events Statistics 
Back to Top

SQL Statistics v$sqlarea

本节按各类资源分别列出对资源消耗最严重的SQL语句,并显示它们所占统计期内所有资源的比例,这给出咱们调优指南。例如在一个系统中,CPU资源是系统性能瓶颈所在,那么优化buffer gets最多的SQL语句将得到最大效果。在一个I/O等待是最严重事件的系统中,调优的目标应该是physical IOs最多的SQL语句。

STATSPACK报告中,没有完整的SQL语句,可以使用报告中的Hash Value经过下面语句从数据库中查到:

select sql_text

from stats$sqltext

where hash_value = &hash_value

order by piece;

Back to Top

SQL ordered by Elapsed Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

Elapsed Time (s)

CPU Time (s)

Executions

Elap per Exec (s)

% Total DB Time

SQL Id

SQL Module

SQL Text

93

57

1

93.50

14.10

d8z0u8hgj8xdy

cuidmain@HPGICCI1 (TNS V1-V3)

insert into CUID select CUID_...

76

75

172,329

0.00

11.52

4vja2k2gdtyup

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

58

42

1

58.04

8.75

569r5k05drsj7

cumimain@HPGICCI1 (TNS V1-V3)

insert into CUMI select CUSV_...

51

42

1

50.93

7.68

ackxqhnktxnbc

cusmmain@HPGICCI1 (TNS V1-V3)

insert into CUSM select CUSM_...

38

36

166,069

0.00

5.67

7gtztzv329wg0

 

select c.name, u.name from co...

35

3

1

35.00

5.28

6z06gcfw39pkd

SQL*Plus

SELECT F.TABLESPACE_NAME, TO_...

23

23

172,329

0.00

3.46

1dm3bq36vu3g8

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into iccifnsact values...

15

11

5

2.98

2.25

djs2w2f17nw2z

 

DECLARE job BINARY_INTEGER := ...

14

14

172,983

0.00

2.16

7wwv1ybs9zguz

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_AD...

13

13

172,337

0.00

2.00

gmn2w09rdxn14

load_oldnewact@HPGICCI1 (TNS V1-V3)

insert into OLDNEWACT values ...

13

13

166,051

0.00

1.89

chjmy0dxf9mbj

icci_migact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

10

4

1

9.70

1.46

0yv9t4qb1zb2b

cuidmain@HPGICCI1 (TNS V1-V3)

select CUID_CUST_NO , CUID_ID_...

10

8

5

1.91

1.44

1crajpb7j5tyz

 

INSERT INTO STATS$SGA_TARGET_A...

8

8

172,329

0.00

1.25

38apjgr0p55ns

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCICCS set CCSMAXOVER...

8

8

172,983

0.00

1.16

5c4qu2zmj3gux

load_fnsact@HPGICCI1 (TNS V1-V3)

select * from ICCIPRODCODE wh...

Back to SQL Statistics 
Back to Top

SQL ordered by CPU Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

CPU Time (s)

Elapsed Time (s)

Executions

CPU per Exec (s)

% Total DB Time

SQL Id

SQL Module

SQL Text

75

76

172,329

0.00

11.52

4vja2k2gdtyup

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

57

93

1

57.31

14.10

d8z0u8hgj8xdy

cuidmain@HPGICCI1 (TNS V1-V3)

insert into CUID select CUID_...

42

51

1

42.43

7.68

ackxqhnktxnbc

cusmmain@HPGICCI1 (TNS V1-V3)

insert into CUSM select CUSM_...

42

58

1

42.01

8.75

569r5k05drsj7

cumimain@HPGICCI1 (TNS V1-V3)

insert into CUMI select CUSV_...

36

38

166,069

0.00

5.67

7gtztzv329wg0

 

select c.name, u.name from co...

23

23

172,329

0.00

3.46

1dm3bq36vu3g8

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into iccifnsact values...

14

14

172,983

0.00

2.16

7wwv1ybs9zguz

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_AD...

13

13

172,337

0.00

2.00

gmn2w09rdxn14

load_oldnewact@HPGICCI1 (TNS V1-V3)

insert into OLDNEWACT values ...

13

13

166,051

0.00

1.89

chjmy0dxf9mbj

icci_migact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

11

15

5

2.23

2.25

djs2w2f17nw2z

 

DECLARE job BINARY_INTEGER := ...

8

8

172,329

0.00

1.25

38apjgr0p55ns

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCICCS set CCSMAXOVER...

8

10

5

1.60

1.44

1crajpb7j5tyz

 

INSERT INTO STATS$SGA_TARGET_A...

8

8

172,983

0.00

1.16

5c4qu2zmj3gux

load_fnsact@HPGICCI1 (TNS V1-V3)

select * from ICCIPRODCODE wh...

4

10

1

3.54

1.46

0yv9t4qb1zb2b

cuidmain@HPGICCI1 (TNS V1-V3)

select CUID_CUST_NO , CUID_ID_...

3

35

1

3.13

5.28

6z06gcfw39pkd

SQL*Plus

SELECT F.TABLESPACE_NAME, TO_...

Back to SQL Statistics 
Back to Top

SQL ordered by Gets

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • Total Buffer Gets: 16,648,792
  • Captured SQL account for 97.9% of Total

这一部分,经过Buffer Gets对SQL语句进行排序,即经过它执行了多少个逻辑I/O来排序。顶端的注释代表一个PL/SQL单元的缓存得到(Buffer Gets)包括被这个代码块执行的全部SQL语句的Buffer Gets。所以将常常在这个列表的顶端看到PL/SQL过程,由于存储过程执行的单独的语句的数目被总计出来。在这里的Buffer Gets是一个累积值,因此这个值大并不必定意味着这条语句的性能存在问题。一般咱们能够经过对比该条语句的Buffer Gets和physical reads值,若是这两个比较接近,确定这条语句是存在问题的,咱们能够经过执行计划来分析,为何physical reads的值如此之高。另外,咱们在这里也能够关注gets per exec的值,这个值若是太大,代表这条语句可能使用了一个比较差的索引或者使用了不当的表链接。

另外说明一点:大量的逻辑读每每伴随着较高的CPU消耗。因此不少时候咱们看到的系统CPU将近100%的时候,不少时候就是SQL语句形成的,这时候咱们能够分析一下这里逻辑读大的SQL。

select * from 

          (select substr(sql_text,1,40) sql,   buffer_gets,

executions, buffer_gets/executions "Gets/Exec",   

          hash_value,address

          from v$sqlarea        

          where  buffer_gets > 0 and executions>0

          order by buffer_gets desc) 

          where rownum <= 10 ;

Buffer Gets

Executions

Gets per Exec

%Total

CPU Time (s)

Elapsed Time (s)

SQL Id

SQL Module

SQL Text

3,305,363

172,329

19.18

19.85

74.57

76.41

4vja2k2gdtyup

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

2,064,414

1

2,064,414.00

12.40

57.31

93.50

d8z0u8hgj8xdy

cuidmain@HPGICCI1 (TNS V1-V3)

insert into CUID select CUID_...

1,826,869

166,069

11.00

10.97

35.84

37.60

7gtztzv329wg0

 

select c.name, u.name from co...

1,427,648

172,337

8.28

8.58

12.97

13.29

gmn2w09rdxn14

load_oldnewact@HPGICCI1 (TNS V1-V3)

insert into OLDNEWACT values ...

1,278,667

172,329

7.42

7.68

22.85

22.94

1dm3bq36vu3g8

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into iccifnsact values...

1,216,367

1

1,216,367.00

7.31

42.43

50.93

ackxqhnktxnbc

cusmmain@HPGICCI1 (TNS V1-V3)

insert into CUSM select CUSM_...

1,107,305

1

1,107,305.00

6.65

42.01

58.04

569r5k05drsj7

cumimain@HPGICCI1 (TNS V1-V3)

insert into CUMI select CUSV_...

898,868

172,983

5.20

5.40

14.28

14.34

7wwv1ybs9zguz

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_AD...

711,450

166,051

4.28

4.27

12.52

12.55

chjmy0dxf9mbj

icci_migact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

692,996

172,329

4.02

4.16

8.31

8.31

38apjgr0p55ns

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCICCS set CCSMAXOVER...

666,748

166,052

4.02

4.00

6.36

6.36

7v9dyf5r424yh

icci_migact@HPGICCI1 (TNS V1-V3)

select NEWACTNO into :b0 from...

345,357

172,983

2.00

2.07

7.70

7.71

5c4qu2zmj3gux

load_fnsact@HPGICCI1 (TNS V1-V3)

select * from ICCIPRODCODE wh...

231,756

51,633

4.49

1.39

5.75

5.83

49ms69srnaxzj

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCIRPYV values (...

Back to SQL Statistics 
Back to Top

SQL ordered by Reads

  • Total Disk Reads: 322,678
  • Captured SQL account for 66.1% of Total

这部分经过物理读对SQL语句进行排序。这显示引发大部分对这个系统进行读取活动的SQL,即物理I/O。当咱们的系统若是存在I/O瓶颈时,须要关注这里I/O操做比较多的语句。

select * from     

              (select substr(sql_text,1,40) sql,      disk_reads,

executions, disk_reads/executions "Reads/Exec",     

              hash_value,address   

              from v$sqlarea    where disk_reads > 0 and executions >0     

              order by disk_reads desc) where rownum <= 10;

 

Physical Reads

Executions

Reads per Exec

%Total

CPU Time (s)

Elapsed Time (s)

SQL Id

SQL Module

SQL Text

66,286

1

66,286.00

20.54

57.31

93.50

d8z0u8hgj8xdy

cuidmain@HPGICCI1 (TNS V1-V3)

insert into CUID select CUID_...

50,646

1

50,646.00

15.70

3.54

9.70

0yv9t4qb1zb2b

cuidmain@HPGICCI1 (TNS V1-V3)

select CUID_CUST_NO , CUID_ID_...

24,507

1

24,507.00

7.59

42.01

58.04

569r5k05drsj7

cumimain@HPGICCI1 (TNS V1-V3)

insert into CUMI select CUSV_...

21,893

1

21,893.00

6.78

42.43

50.93

ackxqhnktxnbc

cusmmain@HPGICCI1 (TNS V1-V3)

insert into CUSM select CUSM_...

19,761

1

19,761.00

6.12

2.14

6.04

a7nh7j8zmfrzw

cumimain@HPGICCI1 (TNS V1-V3)

select CUSV_CUST_NO from CUMI...

19,554

1

19,554.00

6.06

1.27

3.83

38gak8u2qm11w

SQL*Plus

select count(*) from CUSVAA_T...

6,342

1

6,342.00

1.97

3.13

35.00

6z06gcfw39pkd

SQL*Plus

SELECT F.TABLESPACE_NAME, TO_...

4,385

1

4,385.00

1.36

1.59

2.43

cp5duhcsj72q0

cusmmain@HPGICCI1 (TNS V1-V3)

select CUSM_CUST_ACCT_NO from...

63

5

12.60

0.02

11.17

14.91

djs2w2f17nw2z

 

DECLARE job BINARY_INTEGER := ...

35

1

35.00

0.01

0.08

0.67

1uk5m5qbzj1vt

SQL*Plus

BEGIN dbms_workload_repository...

Back to SQL Statistics 
Back to Top

SQL ordered by Executions

  • Total Executions: 1,675,112
  • Captured SQL account for 99.8% of Total

这部分告诉咱们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询,以观察是否有某些更改逻辑的方法以免必须如此频繁的执行这些查询,这多是颇有用的。或许一个查询正在一个循环的内部执行,并且它可能在循环的外部执行一次,能够设计简单的算法更改以减小必须执行这个查询的次数。即便它运行的飞快,任何被执行几百万次的操做都将开始耗尽大量的时间。

select * from      

              (select substr(sql_text,1,40) sql,      executions,

rows_processed, rows_processed/executions "Rows/Exec",   

              hash_value,address   

              from v$sqlarea    where executions > 0

              order by executions desc) where rownum <= 10 ;

 

Executions

Rows Processed

Rows per Exec

CPU per Exec (s)

Elap per Exec (s)

SQL Id

SQL Module

SQL Text

172,983

172,329

1.00

0.00

0.00

5c4qu2zmj3gux

load_fnsact@HPGICCI1 (TNS V1-V3)

select * from ICCIPRODCODE wh...

172,983

172,329

1.00

0.00

0.00

7wwv1ybs9zguz

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_AD...

172,337

172,337

1.00

0.00

0.00

gmn2w09rdxn14

load_oldnewact@HPGICCI1 (TNS V1-V3)

insert into OLDNEWACT values ...

172,329

172,329

1.00

0.00

0.00

1dm3bq36vu3g8

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into iccifnsact values...

172,329

172,329

1.00

0.00

0.00

38apjgr0p55ns

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCICCS set CCSMAXOVER...

172,329

6,286

0.04

0.00

0.00

4vja2k2gdtyup

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

166,069

166,069

1.00

0.00

0.00

7gtztzv329wg0

 

select c.name, u.name from co...

166,052

166,052

1.00

0.00

0.00

7v9dyf5r424yh

icci_migact@HPGICCI1 (TNS V1-V3)

select NEWACTNO into :b0 from...

166,051

166,051

1.00

0.00

0.00

chjmy0dxf9mbj

icci_migact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

51,740

51,740

1.00

0.00

0.00

bu8tnqr3xv25q

load_fnsact@HPGICCI1 (TNS V1-V3)

select count(*) into :b0 fro...

51,633

51,633

1.00

0.00

0.00

49ms69srnaxzj

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCIRPYV values (...

Back to SQL Statistics 
Back to Top

SQL ordered by Parse Calls

  • Total Parse Calls: 182,780
  • Captured SQL account for 99.0% of Total

在这一部分,主要显示PARSE与EXECUTIONS的对比状况。若是PARSE/EXECUTIONS>1,每每说明这个语句可能存在问题:没有使用绑定变量,共享池设置过小,cursor_sharing被设置为exact,没有设置session_cached_cursors等等问题。

select * from      

              (select substr(sql_text,1,40) sql,      parse_calls,

executions, hash_value,address     

              from v$sqlarea    where parse_calls > 0

              order by parse_calls desc) where rownum <= 10 ;

 

Parse Calls

Executions

% Total Parses

SQL Id

SQL Module

SQL Text

166,069

166,069

90.86

7gtztzv329wg0

 

select c.name, u.name from co...

6,304

6,304

3.45

2ym6hhaq30r73

 

select type#, blocks, extents,...

2,437

2,438

1.33

bsa0wjtftg3uw

 

select file# from file$ where ...

1,568

1,568

0.86

9qgtwh66xg6nz

 

update seg$ set type#=:4, bloc...

1,554

1,554

0.85

aq4js2gkfjru8

 

update tsq$ set blocks=:3, max...

444

444

0.24

104pd9mm3fh9p

 

select blocks, maxblocks, gran...

421

421

0.23

350f5yrnnmshs

 

lock table sys.mon_mods$ in ex...

421

421

0.23

g00cj285jmgsw

 

update sys.mon_mods$ set inser...

86

86

0.05

3m8smr0v7v1m6

 

INSERT INTO sys.wri$_adv_messa...

81

81

0.04

f80h0xb1qvbsk

 

SELECT sys.wri$_adv_seq_msggro...

Back to SQL Statistics 
Back to Top

SQL ordered by Sharable Memory

No data exists for this section of the report.

在这一部分,主要是针对shared memory占用的状况进行排序。

select * from      

              (select substr(sql_text,1,40) sql,      sharable_mem,

executions, hash_value,address     

              from v$sqlarea    where sharable_mem > 1048576   

              order by sharable_mem desc) 

              where rownum <= 10;

 

Back to SQL Statistics 
Back to Top

Running Time top 10 sql

select * from

              (select t.sql_fulltext, 

              (t.last_active_time-to_date(t.first_load_time,'yyyy-mm-dd hh24:mi:ss'))*24*60,

              disk_reads,buffer_gets,rows_processed,     

              t.last_active_time,t.last_load_time,t.first_load_time

              from v$sqlarea t order by t.first_load_time desc)     

              where rownum < 10;

 

SQL ordered by Version Count

No data exists for this section of the report.

在这一部分,主要是针对SQL语句的多版本进行排序。相同的SQL文本,可是不一样属性,好比对象owner不一样,会话优化模式不一样、类型不一样、长度不一样和绑定变量不一样等等的语句,他们是不能共享的,因此再缓存中会存在多个不一样的版本。这固然就形成了资源上的更多的消耗。

Back to SQL Statistics 
Back to Top

SQL ordered by Cluster Wait Time

Cluster Wait Time (s)

CWT % of Elapsd Time

Elapsed Time(s)

CPU Time(s)

Executions

SQL Id

SQL Module

SQL Text

10.96

11.72

93.50

57.31

1

d8z0u8hgj8xdy

cuidmain@HPGICCI1 (TNS V1-V3)

insert into CUID select CUID_...

4.21

7.25

58.04

42.01

1

569r5k05drsj7

cumimain@HPGICCI1 (TNS V1-V3)

insert into CUMI select CUSV_...

3.62

7.12

50.93

42.43

1

ackxqhnktxnbc

cusmmain@HPGICCI1 (TNS V1-V3)

insert into CUSM select CUSM_...

2.39

6.35

37.60

35.84

166,069

7gtztzv329wg0

 

select c.name, u.name from co...

2.38

3.12

76.41

74.57

172,329

4vja2k2gdtyup

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

1.64

16.91

9.70

3.54

1

0yv9t4qb1zb2b

cuidmain@HPGICCI1 (TNS V1-V3)

select CUID_CUST_NO , CUID_ID_...

1.06

3.02

35.00

3.13

1

6z06gcfw39pkd

SQL*Plus

SELECT F.TABLESPACE_NAME, TO_...

0.83

13.76

6.04

2.14

1

a7nh7j8zmfrzw

cumimain@HPGICCI1 (TNS V1-V3)

select CUSV_CUST_NO from CUMI...

0.66

87.90

0.75

0.42

444

104pd9mm3fh9p

 

select blocks, maxblocks, gran...

0.50

13.01

3.83

1.27

1

38gak8u2qm11w

SQL*Plus

select count(*) from CUSVAA_T...

0.50

51.75

0.96

0.79

1,554

aq4js2gkfjru8

 

update tsq$ set blocks=:3, max...

0.33

91.11

0.36

0.33

187

04xtrk7uyhknh

 

select obj#, type#, ctime, mti...

0.33

2.47

13.29

12.97

172,337

gmn2w09rdxn14

load_oldnewact@HPGICCI1 (TNS V1-V3)

insert into OLDNEWACT values ...

0.29

1.26

22.94

22.85

172,329

1dm3bq36vu3g8

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into iccifnsact values...

0.25

10.14

2.43

1.59

1

cp5duhcsj72q0

cusmmain@HPGICCI1 (TNS V1-V3)

select CUSM_CUST_ACCT_NO from...

0.21

27.92

0.74

0.74

1,568

9qgtwh66xg6nz

 

update seg$ set type#=:4, bloc...

0.20

3.49

5.83

5.75

51,633

49ms69srnaxzj

load_fnsact@HPGICCI1 (TNS V1-V3)

insert into ICCIRPYV values (...

0.17

1.39

12.55

12.52

166,051

chjmy0dxf9mbj

icci_migact@HPGICCI1 (TNS V1-V3)

insert into ICCICCS values (:...

0.16

57.64

0.28

0.24

39

cn1gtsav2d5jh

cusvaamain@HPGICCI1 (TNS V1-V3)

BEGIN BEGIN IF (xdb.DBMS...

0.14

74.58

0.19

0.14

121

5ngzsfstg8tmy

 

select o.owner#, o.name, o.nam...

0.11

64.72

0.18

0.15

80

78m9ryygp65v5

cusvaamain@HPGICCI1 (TNS V1-V3)

SELECT /*+ ALL_ROWS */ COUNT(*...

0.11

94.54

0.12

0.01

17

bwt0pmxhv7qk7

 

delete from con$ where owner#=...

0.11

80.26

0.14

0.14

327

53saa2zkr6wc3

 

select intcol#, nvl(pos#, 0), ...

0.08

19.20

0.42

0.24

1

d92h3rjp0y217

 

begin prvt_hdm.auto_execute( :...

0.07

54.97

0.13

0.13

83

7ng34ruy5awxq

 

select i.obj#, i.ts#, i.file#,...

0.06

5.22

1.13

0.72

77

0hhmdwwgxbw0r

 

select obj#, type#, flags, ...

0.06

86.50

0.06

0.06

45

a2any035u1qz1

 

select owner#, name from con$...

0.06

8.19

0.67

0.08

1

1uk5m5qbzj1vt

SQL*Plus

BEGIN dbms_workload_repository...

0.04

75.69

0.06

0.06

87

6769wyy3yf66f

 

select pos#, intcol#, col#, sp...

0.04

48.05

0.09

0.07

7

0pvtkmrrq8usg

 

select file#, block# from seg...

0.04

8.84

0.40

0.40

6,304

2ym6hhaq30r73

 

select type#, blocks, extents,...

0.03

28.15

0.12

0.12

49

b52m6vduutr8j

 

delete from RecycleBin$ ...

0.03

66.23

0.05

0.05

85

1gu8t96d0bdmu

 

select t.ts#, t.file#, t.block...

0.03

67.03

0.05

0.05

38

btzq46kta67dz

DBMS_SCHEDULER

update obj$ set obj#=:6, type#...

0.02

66.73

0.04

0.04

86

3m8smr0v7v1m6

 

INSERT INTO sys.wri$_adv_messa...

0.02

26.94

0.09

0.09

38

0k8h617b8guhf

 

delete from RecycleBin$ ...

0.02

76.76

0.03

0.03

51

9vtm7gy4fr2ny

 

select con# from con$ where ow...

0.02

51.91

0.05

0.05

84

83taa7kaw59c1

 

select name, intcol#, segcol#,...

0.02

0.15

14.91

11.17

5

djs2w2f17nw2z

 

DECLARE job BINARY_INTEGER := ...

0.02

2.12

1.00

0.99

8,784

501v412s13r4m

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_FA...

0.02

53.82

0.03

0.03

39

bdv0rkkssq2jm

cusvaamain@HPGICCI1 (TNS V1-V3)

SELECT count(*) FROM user_poli...

0.01

0.10

14.34

14.28

172,983

7wwv1ybs9zguz

load_fnsact@HPGICCI1 (TNS V1-V3)

update ICCIFNSACT set BORM_AD...

0.01

8.29

0.16

0.13

421

g00cj285jmgsw

 

update sys.mon_mods$ set inser...

0.01

1.65

0.56

0.54

2

84qubbrsr0kfn

 

insert into wrh$_latch (snap...

0.01

22.33

0.04

0.02

26

44au3v5mzpc1c

load_curmmast@HPGICCI1 (TNS V1-V3)

insert into ICCICURMMAST valu...

0.01

0.08

7.71

7.70

172,983

5c4qu2zmj3gux

load_fnsact@HPGICCI1 (TNS V1-V3)

select * from ICCIPRODCODE wh...

Back to SQL Statistics 
Back to Top

对于出如今上面的可疑的sql语句,咱们能够查看语句相关的执行计划,而后分析相关索引等是否合理。

经过语句查看执行计划的方法:

SELECT id,parent_id,LPAD(' ',4*(LEVEL-1))||operation||' '||options||' '||object_name "Execution plan" ,cost,cardinality,bytes

FROM (

SELECT p.* FROM v$sql_plan p,v$sql s WHERE p.address = s.ADDRESS

AND p.hash_value = s.HASH_VALUE

and p.hash_value = '&hash_value'

)

CONNECT BY PRIOR id = parent_id

START WITH id = 0;

    查看,分析,优化索引等在这里就再也不一一描述了。

Complete List of SQL Text

SQL Id

SQL Text

04xtrk7uyhknh

select obj#, type#, ctime, mtime, stime, status, dataobj#, flags, oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null

0hhmdwwgxbw0r

select obj#, type#, flags, related, bo, purgeobj, con# from RecycleBin$ where ts#=:1 and to_number(bitand(flags, 16)) = 16 order by dropscn

0k8h617b8guhf

delete from RecycleBin$ where purgeobj=:1

0pvtkmrrq8usg

select file#, block# from seg$ where type# = 3 and ts# = :1

0v9t4qb1zb2b

select CUID_CUST_NO , CUID_ID_TYPE , CUID_ID_RECNO from CUID_TMP where CHGFLAG='D'

104pd9mm3fh9p

select blocks, maxblocks, grantor#, priv1, priv2, priv3 from tsq$ where ts#=:1 and user#=:2

1crajpb7j5tyz

INSERT INTO STATS$SGA_TARGET_ADVICE ( SNAP_ID , DBID , INSTANCE_NUMBER , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS ) SELECT :B3 , :B2 , :B1 , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS FROM V$SGA_TARGET_ADVICE

1dm3bq36vu3g8

insert into iccifnsact values (:b0, :b1, :b2, null , null , :b3, :b4, GREATEST(:b5, :b6), null , :b7, :b8, null , :b9, :b10, :b6, null , null , null , null , null , :b12, null , null , null , :b13, :b14, null , null , :b15, :b16, :b17)

1gu8t96d0bdmu

select t.ts#, t.file#, t.block#, nvl(t.bobj#, 0), nvl(t.tab#, 0), t.intcols, nvl(t.clucols, 0), t.audit$, t.flags, t.pctfree$, t.pctused$, t.initrans, t.maxtrans, t.rowcnt, t.blkcnt, t.empcnt, t.avgspc, t.chncnt, t.avgrln, t.analyzetime, t.samplesize, t.cols, t.property, nvl(t.degree, 1), nvl(t.instances, 1), t.avgspc_flb, t.flbcnt, t.kernelcols, nvl(t.trigflag, 0), nvl(t.spare1, 0), nvl(t.spare2, 0), t.spare4, t.spare6, ts.cachedblk, ts.cachehit, ts.logicalread from tab$ t, tab_stats$ ts where t.obj#= :1 and t.obj# = ts.obj# (+)

1uk5m5qbzj1vt

BEGIN dbms_workload_repository.create_snapshot; END;

2ym6hhaq30r73

select type#, blocks, extents, minexts, maxexts, extsize, extpct, user#, iniexts, NVL(lists, 65535), NVL(groups, 65535), cachehint, hwmincr, NVL(spare1, 0), NVL(scanhint, 0) from seg$ where ts#=:1 and file#=:2 and block#=:3

350f5yrnnmshs

lock table sys.mon_mods$ in exclusive mode nowait

38apjgr0p55ns

update ICCICCS set CCSMAXOVERDUE=GREATEST(:b0, CCSMAXOVERDUE) where FNSACTNO=:b1

38gak8u2qm11w

select count(*) from CUSVAA_TMP

3m8smr0v7v1m6

INSERT INTO sys.wri$_adv_message_groups (task_id, id, seq, message#, fac, hdr, lm, nl, p1, p2, p3, p4, p5) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13)

44au3v5mzpc1c

insert into ICCICURMMAST values (:b0, :b1, :b2)

49ms69srnaxzj

insert into ICCIRPYV values (:b0, :b1, :b2, :b3, :b4, :b5, :b6, :b7, :b8, :b9, :b10, :b11, :b12, :b13, :b14, :b15, :b16, :b17, :b18, :b19, :b20, :b21, :b22, :b23, :b24, :b25, :b26, :b27, :b28, :b29, :b30, :b31, :b32, :b33, :b34, :b35, :b36, :b37, :b38, :b39, :b40, :b41, :b42, :b43, :b44, :b45, :b46, :b47, :b48, :b49, :b50, :b51)

4vja2k2gdtyup

insert into ICCICCS values (:b0, '', 0, 0, 0, 0, 0, ' ', 0, 0, 0, ' ', '0', null )

501v412s13r4m

update ICCIFNSACT set BORM_FACILITY_NO=:b0 where BORM_MEMB_CUST_AC=:b1

53saa2zkr6wc3

select intcol#, nvl(pos#, 0), col#, nvl(spare1, 0) from ccol$ where con#=:1

569r5k05drsj7

insert into CUMI select CUSV_CUST_NO , CUSV_EDUCATION_CODE , CHGDATE from CUMI_TMP where CHGFLAG<>'D'

5c4qu2zmj3gux

select * from ICCIPRODCODE where PRODCODE=to_char(:b0)

5ngzsfstg8tmy

select o.owner#, o.name, o.namespace, o.remoteowner, o.linkname, o.subname, o.dataobj#, o.flags from obj$ o where o.obj#=:1

6769wyy3yf66f

select pos#, intcol#, col#, spare1, bo#, spare2 from icol$ where obj#=:1

6z06gcfw39pkd

SELECT F.TABLESPACE_NAME, TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE), '999, 999') "USED (MB)", TO_CHAR (F.FREE_SPACE, '999, 999') "FREE (MB)", TO_CHAR (T.TOTAL_SPACE, '999, 999') "TOTAL (MB)", TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)), '999')||' %' PER_FREE FROM ( SELECT TABLESPACE_NAME, ROUND (SUM (BLOCKS*(SELECT VALUE/1024 FROM V$PARAMETER WHERE NAME = 'db_block_size')/1024) ) FREE_SPACE FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME ) F, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES/1048576)) TOTAL_SPACE FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) T WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME

78m9ryygp65v5

SELECT /*+ ALL_ROWS */ COUNT(*) FROM ALL_POLICIES V WHERE V.OBJECT_OWNER = :B3 AND V.OBJECT_NAME = :B2 AND (POLICY_NAME LIKE '%xdbrls%' OR POLICY_NAME LIKE '%$xd_%') AND V.FUNCTION = :B1

7gtztzv329wg0

select c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :1 and c.owner# = u.user#

7ng34ruy5awxq

select i.obj#, i.ts#, i.file#, i.block#, i.intcols, i.type#, i.flags, i.property, i.pctfree$, i.initrans, i.maxtrans, i.blevel, i.leafcnt, i.distkey, i.lblkkey, i.dblkkey, i.clufac, i.cols, i.analyzetime, i.samplesize, i.dataobj#, nvl(i.degree, 1), nvl(i.instances, 1), i.rowcnt, mod(i.pctthres$, 256), i.indmethod#, i.trunccnt, nvl(c.unicols, 0), nvl(c.deferrable#+c.valid#, 0), nvl(i.spare1, i.intcols), i.spare4, i.spare2, i.spare6, decode(i.pctthres$, null, null, mod(trunc(i.pctthres$/256), 256)), ist.cachedblk, ist.cachehit, ist.logicalread from ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols, min(to_number(bitand(defer, 1))) deferrable#, min(to_number(bitand(defer, 4))) valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#

7v9dyf5r424yh

select NEWACTNO into :b0 from OLDNEWACT where OLDACTNO=:b1

7wwv1ybs9zguz

update ICCIFNSACT set BORM_ADV_DATE=:b0, BOIS_MATURITY_DATE=:b1, BOIS_UNPD_BAL=:b2, BOIS_UNPD_INT=:b3, BOIS_BAL_FINE=:b4, BOIS_INT_FINE=:b5, BOIS_FINE_FINE=:b6, BORM_LOAN_TRM=:b7, BORM_FIVE_STAT=:b8, BOIS_ARREARS_CTR=:b9, BOIS_ARREARS_SUM=:b10 where BORM_MEMB_CUST_AC=:b11

83taa7kaw59c1

select name, intcol#, segcol#, type#, length, nvl(precision#, 0), decode(type#, 2, nvl(scale, -127/*MAXSB1MINAL*/), 178, scale, 179, scale, 180, scale, 181, scale, 182, scale, 183, scale, 231, scale, 0), null$, fixedstorage, nvl(deflength, 0), default$, rowid, col#, property, nvl(charsetid, 0), nvl(charsetform, 0), spare1, spare2, nvl(spare3, 0) from col$ where obj#=:1 order by intcol#

4qubbrsr0kfn

insert into wrh$_latch (snap_id, dbid, instance_number, latch_hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time) select :snap_id, :dbid, :instance_number, hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time from v$latch order by hash

9qgtwh66xg6nz

update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18 where ts#=:1 and file#=:2 and block#=:3

9vtm7gy4fr2ny

select con# from con$ where owner#=:1 and name=:2

a2any035u1qz1

select owner#, name from con$ where con#=:1

a7nh7j8zmfrzw

select CUSV_CUST_NO from CUMI_TMP where CHGFLAG='D'


 

Back to SQL Statistics 
Back to Top

Instance Activity Statistics

Back to Top

Instance Activity Stats

Statistic

Total

per Second

per Trans

CPU used by this session

23,388

4.95

4.18

CPU used when call started

21,816

4.61

3.90

CR blocks created

2,794

0.59

0.50

Cached Commit SCN referenced

237,936

50.33

42.50

Commit SCN cached

3

0.00

0.00

DB time

583,424

123.41

104.22

DBWR checkpoint buffers written

402,781

85.20

71.95

DBWR checkpoints

9

0.00

0.00

DBWR fusion writes

255

0.05

0.05

DBWR object drop buffers written

0

0.00

0.00

DBWR thread checkpoint buffers written

221,341

46.82

39.54

DBWR transaction table writes

130

0.03

0.02

DBWR undo block writes

219,272

46.38

39.17

DFO trees parallelized

16

0.00

0.00

PX local messages recv'd

40

0.01

0.01

PX local messages sent

40

0.01

0.01

PX remote messages recv'd

80

0.02

0.01

PX remote messages sent

80

0.02

0.01

Parallel operations not downgraded

16

0.00

0.00

RowCR - row contention

9

0.00

0.00

RowCR attempts

14

0.00

0.00

RowCR hits

5

0.00

0.00

SMON posted for undo segment recovery

0

0.00

0.00

SMON posted for undo segment shrink

9

0.00

0.00

SQL*Net roundtrips to/from client

1,544,063

326.62

275.82

active txn count during cleanout

276,652

58.52

49.42

application wait time

1,620

0.34

0.29

auto extends on undo tablespace

0

0.00

0.00

background checkpoints completed

7

0.00

0.00

background checkpoints started

9

0.00

0.00

background timeouts

21,703

4.59

3.88

branch node splits

337

0.07

0.06

buffer is not pinned count

1,377,184

291.32

246.01

buffer is pinned count

20,996,139

4,441.37

3,750.65

bytes received via SQL*Net from client

7,381,397,183

1,561,408.36

1,318,577.56

bytes sent via SQL*Net to client

149,122,035

31,544.22

26,638.45

calls to get snapshot scn: kcmgss

1,696,712

358.91

303.09

calls to kcmgas

433,435

91.69

77.43

calls to kcmgcs

142,482

30.14

25.45

change write time

4,707

1.00

0.84

cleanout - number of ktugct calls

282,045

59.66

50.38

cleanouts and rollbacks - consistent read gets

55

0.01

0.01

cleanouts only - consistent read gets

2,406

0.51

0.43

cluster key scan block gets

21,886

4.63

3.91

cluster key scans

10,540

2.23

1.88

cluster wait time

2,855

0.60

0.51

commit batch/immediate performed

294

0.06

0.05

commit batch/immediate requested

294

0.06

0.05

commit cleanout failures: block lost

2,227

0.47

0.40

commit cleanout failures: callback failure

750

0.16

0.13

commit cleanout failures: cannot pin

4

0.00

0.00

commit cleanouts

427,610

90.45

76.39

commit cleanouts successfully completed

424,629

89.82

75.85

commit immediate performed

294

0.06

0.05

commit immediate requested

294

0.06

0.05

commit txn count during cleanout

111,557

23.60

19.93

concurrency wait time

515

0.11

0.09

consistent changes

1,716

0.36

0.31

consistent gets

5,037,471

1,065.59

899.87

由consistent gets,db block gets和physical reads这三个值,咱们也能够计算获得buffer hit ratio,计算的公式以下: buffer hit ratio = 100*(1-physical reads /(consistent gets+ db block gets)),例如在这里,咱们能够计算获得:buffer hit ratio =100*(1-26524/(16616758+2941398))= 99.86

consistent gets - examination

2,902,016

613.87

518.40

consistent gets direct

0

0.00

0.00

consistent gets from cache

5,037,471

1,065.59

899.87

current blocks converted for CR

0

0.00

0.00

cursor authentications

434

0.09

0.08

data blocks consistent reads - undo records applied

1,519

0.32

0.27

db block changes

8,594,158

1,817.95

1,535.22

db block gets

11,611,321

2,456.18

2,074.19

db block gets direct

1,167,830

247.03

208.62

db block gets from cache

10,443,491

2,209.14

1,865.58

deferred (CURRENT) block cleanout applications

20,786

4.40

3.71

dirty buffers inspected

25,007

5.29

4.47

脏数据从LRU列表中老化,A value here indicates that the DBWR is not keeping up。若是这个值大于0,就须要考虑增长DBWRs。

dirty buffers inspected: This is the number of dirty (modified) data buffers that were aged out on the LRU list. You may benefit by adding more DBWRs.If it is greater than 0, consider increasing the database writes.

drop segment calls in space pressure

0

0.00

0.00

enqueue conversions

6,734

1.42

1.20

enqueue releases

595,149