Oracle优化

如何分析awr报告

时间:2013-9-7 20:06:46  作者:www.solgle.com  来源:说歌社区  查看:923  评论:0
内容摘要:第一次看到awr报告,里面包含很多东西,完全不知道从哪里看起也不知道各项指标都是什么含义,从头到尾看了一遍,啥也没有看到,看了后面忘了前面的,花费一天的时间去熟悉它,在网上查资料对着报告一项项的熟悉了一遍DB NameDB IdInstanceInst numStartup Ti...

第一次看到awr报告,里面包含很多东西,完全不知道从哪里看起也不知道各项指标都是什么含义,从头到尾看了一遍,啥也没有看到,看了后面忘了前面的,花费一天的时间去熟悉它,在网上查资料对着报告一项项的熟悉了一遍

 

DB Name

DB Id

Instance

Inst num

Startup Time

Release

RAC

Db10

663168021

Db10

1

28-5 -12 22:05

11.2.0.1.0

NO

 

 

 

Host Name

Platform

CPUs

Cores

Sockets

Memory (GB)

PC-200910080511

Microsoft Windows IA (32-bit)

2

2

1

.75

 

 

 

 

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

73

28-5 -12 22:28:57

23

1.5

End Snap:

74

28-5 -12 23:00:43

23

1.5

Elapsed:

 

31.76 (mins)

 

 

DB Time:

 

0.10 (mins)

 

 

 

DB Name :数据库名字 DBid: 数据库id

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。在31分钟里,数据库耗时0.1分钟,数据中显示系统有2CPU

Load Profile

 

 

Per Second

Per Transaction

Per Exec

Per Call

DB Time(s):

0.0

0.0

0.00

0.02

DB CPU(s):

0.0

0.0

0.00

0.02

Redo size:

5,896.4

59,450.5

 

 

Logical reads:

71.9

724.7

 

 

Block changes:

41.1

414.7

 

 

Physical reads:

2.2

21.9

 

 

Physical writes:

0.9

9.2

 

 

User calls:

0.2

1.8

 

 

Parses:

3.7

37.6

 

 

Hard parses:

0.3

2.5

 

 

W/A MB processed:

0.0

0.2

 

 

Logons:

0.1

0.6

 

 

Executes:

8.1

81.7

 

 

Rollbacks:

0.0

0.0

 

 

Transactions:

0.1

 

 

 

 

Load Profile

 Per Second      Per Transaction

这两部分是数据库资源负载的一个明细列表,分割成每秒钟的资源负载和每个事务的资源负载情况,性能指标的含义如下:

redo size: 每秒/每个事务 产生的redo量 (单位字节)

logical reads: 每秒/每个事务 产生的逻辑读的块数

block changes: 每秒/每个事务 改变的数据块数

physical reads: 每秒/每个事务 产生的物理读

physical writes: 每秒/每个事务 产生的物理写的块数

user calls: 每秒/每个事务 用户的调用次数

parses: 每秒/每个事务 分析次数

hard parses: 每秒/每个事务 硬分析次数

sorts: 每秒/每个事务 排序次数

logons: 每秒/每个事务 登录数据库次数

executes: 每秒/每个事务 SQL的执行次数

rollbacks: 每秒/每个事物回滚次数

transactions: 每秒的事务数

Instance Efficiency Percentages (Target 100%)

 

Buffer Nowait %:

100.00

Redo NoWait %:

100.00

Buffer Hit %:

96.98

In-memory Sort %:

100.00

Library Hit %:

90.91

Soft Parse %:

93.27

Execute to Parse %:

53.96

Latch Hit %:

99.99

Parse CPU to Parse Elapsd %:

64.26

% Non-Parse CPU:

67.81

 

 

Buffer Nowait:表示在内存获得数据的未等待比例。

buffer hit:表示进程从内存中找到数据块的比率,内存数据块命中率

Redo NoWait:表示在LOG缓冲区获得BUFFER的未等待比例。

library hit:表示共享池中SQL解析的命中率

Latch HitLatch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。

Parse CPU to ParseElapsd解析总时间中消耗总CPU的时间百分比

Non-Parse CPU SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。

Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

In-memory Sort:在内存中排序的比率,如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA

Soft Parse:软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。

 

Shared Pool Statistics

 

 

Begin

End

Memory Usage %:

84.18

83.00

% SQL with executions>1:

74.54

76.34

% Memory for SQL w/exec>1:

78.06

73.38

 

Memory Usage %:对于一个已经运行一段时间的数据库来说,共享池内存使用率,应该稳定在75%-90%间,如果太小,说明Shared Pool有浪费,而如果高于90,说明共享池中有争用,内存不足。

SQL with executions>1:执行次数大于1sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。

Memory for SQL w/exec>1:执行次数大于1SQL消耗内存的占比。

Top 5 Timed Foreground Events

 

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

DB CPU

 

5

 

87.64

 

db file sequential read

258

1

5

22.30

User I/O

library cache load lock

1

0

87

1.45

Concurrency

db file scattered read

17

0

3

0.85

User I/O

log file sync

35

0

1

0.77

Commit

 

这是报告概要的最后一节,显示了系统中最严重的5个等待,按所占等待时间的比例倒序列示。当我们调优时,总希望观察到最显著的效果,因此应当从这里入手确定我们下一步做什么。

通常,在没有问题的数据库中,CPUtime总是列在第一个 

 

SQL Statistics

  • SQL ordered by Elapsed Time
  • SQL ordered by CPU Time
  • SQL ordered by User I/O Wait Time
  • SQL ordered by Gets
  • SQL ordered by Reads
  • SQL ordered by Physical Reads (UnOptimized)
  • SQL ordered by Executions
  • SQL ordered by Parse Calls
  • SQL ordered by Sharable Memory
  • SQL ordered by Version Count
  • Complete List of SQL Text

二、解析报告

1.SQL ordered by Elapsed Time

记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和,而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)

Elapsed Time(S): SQL语句执行用总时长,此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间,而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s): SQL语句执行时CPU占用时间总时长,此时间会小于等于Elapsed Time时间。单位时间为秒。

Executions: SQL语句在监控范围内的执行次数总计。

Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

% Total DB Time: SQLElapsed Time时间占数据库总时间的百分比。

SQL ID: SQL语句的ID编号,点击之后就能导航到下边的SQL详细列表中,点击IE的返回可以回到当前SQL ID的地方。

SQL Module: 显示该SQL是用什么方式连接到数据库执行的,如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

SQL Text: 简单的sql提示,详细的需要点击SQL ID

2. SQL ordered by CPU Time:

记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和,而不是单次SQL执行时间)

3. SQL ordered by Gets:

记录了执行占总buffer gets(逻辑IO)TOP SQL(请注意是监控范围内该SQL的执行占Gets总和,而不是单次SQL执行所占的Gets).

4. SQL ordered by Reads:

记录了执行占总磁盘物理读(物理IO)TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和,而不是单次SQL执行所占的磁盘物理读)

5. SQL ordered by Executions:

记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

6. SQL ordered by Parse Calls:

记录了SQL的软解析次数的TOP SQL

7. SQL ordered by Sharable Memory:

记录了SQL占用library cache的大小的TOP SQL

Sharable Mem (b):占用library cache的大小。单位是byte

8. SQL ordered by Version Count:

记录了SQL的打开子游标的TOP SQL

 

标签:如何分析awr报告 

solgle.com 版权所有,欢迎分享!!!

相关文章
    相关评论
       Copyright © 2013-2020 solgle.com,All rights reserved.[solgle.com] 公安机关备案号:51010802000219
    Email:solgle@solgle.com; weixin:cd1008610000 ICP:蜀ICP备14011070号-1