awr性能问题排查第一篇(r3笔记第42天)

对于awr,里面涵盖的内容比较杂,有时候看报告的时候总是不知道该怎么下手。时间长了,可能会有一些阅读习惯或者心得。今天在看大师chris lawson的一篇博文对于awr的一些心得(http://www.oraclemagician.com/white_papers/10awr.pdf ),还是蛮有收获,赶紧按照这个方子来细细品味一番。 首先是查看等待事件,这个也是老规矩。 不过先把db time先附上,更有针对性。 这是一个10分钟的awr报告,基于Linux平台,11gR2 64位。

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

17148

31-Oct-14 13:20:02

3397

5.6

End Snap:

17149

31-Oct-14 13:30:03

3471

5.7

Elapsed:

10.01 (mins)

DB Time:

262.49 (mins)

Top 5 Timed Foreground Events

Event

Waits

Time(s)

Avg wait (ms)

% DB time

Wait Class

db file sequential read

7,138,268

9,948

1

63.16

User I/O

DB CPU

4,405

27.97

direct path read

104,507

903

9

5.73

User I/O

db file parallel read

103,319

336

3

2.13

User I/O

log file sync

49,187

282

6

1.79

Commit

-->查看sequential read指标 这个指标很实用,可以在不同的平台间进行比较,但是scattered read这种指标就不好比较了。 延迟一般需要在10ms以下,或者至少100 reads/sec,在基于SAN存储缓存数据的情况下,sequential read的指标有时候会保持在2ms左右,这个只能说明SAN已经把数据转化为缓存了,倒不能说明硬盘驱动确实很快。 上面的awr可以看到平均的延迟是在1ms以内,算是正常。 -->查看top elapsed time sql 这个时候可以根据elapsed time得到一个sql执行情况的概览。查看这个的主要目的就是得到执行时间较长的sql语句。按照10分钟对的一个频度,executions为0的sql都需要格外注意,同时兼顾所占的比例。

SQL ordered by Elapsed Time

Elapsed Time (s)

Executions

Elapsed Time per Exec (s)

%Total

%CPU

%IO

SQL Id

SQL Text

1,243.85

29

42.89

7.90

7.32

94.81

cjxrg4qpadvgw

SELECT .

942.47

27

34.91

5.98

7.81

95.75

5y3d011ygwfyx

SELECT

613.45

0

3.90

4.81

97.32

9yn2xdw7uy0bq

select /*+ index(s SERVICE_

606.64

555

1.09

3.85

94.74

4.89

7yp93zzstn5gh

update (select /*+ index(

602.56

0

3.83

14.57

90.57

0cdthzpx2jn4q

SELECT

602.53

0

3.83

4.70

97.30

b4c5cvdza03m3

SELECT

578.66

31

18.67

3.67

11.61

92.22

cc9x1wp2tdgdx

SELECT

547.03

1

547.03

3.47

78.67

17.69

gbqz84d1jggdq

/* MMO_Memo_getMemoList_1 */ S...

523.83

3

174.61

3.33

29.21

72.21

4gz51fphuarsw

/*ProcInstScanner_selectAv...

496.38

0

3.15

4.73

96.39

6gvd0gbp58kbc

INSERT INTO ..

420.94

6

70.16

2.67

48.53

49.96

00jrngwmz2vxx

select...

标黄的部分就是参考的依据,可以根据elapsed time和executions来做一个评估。 -->查看db time 这个部分可以根据time model的部分得到。这个部分能够得到一个大体的比例,看看db time都主要耗在哪些方面了。

Statistic Name

Time (s)

% of DB Time

sql execute elapsed time

14,854.47

94.32

DB CPU

4,404.99

27.97

parse time elapsed

64.23

0.41

PL/SQL execution elapsed time

36.26

0.23

sequence load elapsed time

24.11

0.15

hard parse elapsed time

8.79

0.06

connection management call elapsed time

7.85

0.05

RMAN cpu time (backup/restore)

7.74

0.05

inbound PL/SQL rpc elapsed time

6.28

0.04

repeated bind elapsed time

0.11

0.00

hard parse (sharing criteria) elapsed time

0.06

0.00

failed parse elapsed time

0.03

0.00

PL/SQL compilation elapsed time

0.01

0.00

DB time

15,749.31

background elapsed time

1,394.65

background cpu time

68.34

-->查看硬盘读的消耗部分 通过这个部分可以得到哪些sql正在进行大量的硬盘读,通过sql order by reads来得到。 经过分析 sql(gbqz84d1jggdq)占用了22%的硬盘读,比例是很高的,查看sql语句发现走的是一个全表扫描,表是亿级的大表。 sql(00jrngwmz2vxx)使用union的地方存在问题,导致了全表扫描,细节可以参考http://blog.itpub.net/23718752/viewspace-1209397/ 已经做了完整的调优解释。 sql(4gz51fphuarsw,6fu3z8pqd2y9g)是产品线的两个通用sql,已经做了优化,其中有个大表做了全表扫描加并行,相对了最快的方式了。 sql(98dyqu3xsgyf5)是一个简单的select 查询,但是也走了全表扫描,经过排查发现这个大表竟然在最开始规划的时候丢掉了索引,所以这个问题也是一个比较纠结的错误。需要协调解决。

Physical Reads

Executions

Reads per Exec

%Total

Elapsed Time (s)

%CPU

%IO

SQL Id

SQL Text

8,901,984

1

8,901,984.00

22.37

547.03

78.67

17.69

gbqz84d1jggdq

/* MMO_Memo_getMemoList_1 */ S...

6,712,998

6

1,118,833.00

16.87

420.94

48.53

49.96

00jrngwmz2vxx

/* AR9_AR9GetPaymentSMS_select...

5,957,336

3

1,985,778.67

14.97

523.83

29.21

72.21

4gz51fphuarsw

/* CL_ProcInstScanner_selectAv...

4,880,228

3

1,626,742.67

12.26

309.94

18.47

78.67

6fu3z8pqd2y9g

/* CL_WaitScanner_selectWorkab...

2,015,674

36

55,990.94

5.06

94.81

27.40

70.35

98dyqu3xsgyf5

/* null_CL9CrdMntrExtract_sele...

-->查看logical reads 这个部分可以排查出那些执行效率低下的sql语句。 查看以下的几个sql, sql(7yp93zzstn5gh)消耗了大量的逻辑读,经过查看,这个sql语句没有问题,但是表级存在着大量的碎片,一个分区表只有几十条数据,但是blocks却有几十万。 sql(1hg2wcuapy3y3)查看执行计划时,发现执行计划的消耗太高。cost达到近 273K,这条sql语句还是需要好好排查一番。

Buffer Gets

Executions

Gets per Exec

%Total

Elapsed Time (s)

%CPU

%IO

SQL Id

SQL Module

SQL Text

509,827,210

555

918,607.59

61.98

606.64

94.74

4.89

7yp93zzstn5gh

B1Manager@ccbdbpr1 (TNS V1-V3)

update (select /*+ index(B1_...

30,887,996

14

2,206,285.43

3.76

25.51

99.95

0.04

1hg2wcuapy3y3

JDBC Thin Client

select un_request.run_mod...

-->查看commit频率 这个部分可以查看是否日志切换较为频繁,或者在进行着大量的事物处理,可以看看用户进行commit的频度

Instance Activity Stats

Statistic

Total

per Second

per Trans

user calls

7,073,740

11,777.75

216.38

user commits

32,485

54.09

0.99

user rollbacks

207

0.34

0.01

-->查看系统负载 这个部分可以查看系统级的一些指标,如果时间较长,就有多行的数据可以参考。总体来看iowait的比例不高。

Operating System Statistics - Detail

Snap Time

Load

%busy

%user

%sys

%idle

%iowait

31-Oct 13:20:02

38.14

31-Oct 13:30:03

39.55

21.82

17.03

3.41

78.18

0.19

-->查看热对象 可以通过segments by logical reads来得到一些比较热的对象,可能是表,或者索引。 如果比例很高,可以通过这些热对象从sql列表中排查一下,到底是哪些sql语句和这个热对象相关。可能sql语句单独执行很快,多个并发的进程时速度就会受到影响了。

Owner

Tablespace Name

Object Name

Subobject Name

Obj. Type

Logical Reads

%Total

APPO

INDXS01

CYCLE_GROUPS_PK

INDEX

41,559,296

5.05

EFWORK

DATAL01

OFFER

TABLE

20,566,400

2.50

APPO

DATAS01

STEP_INST

TABLE

10,610,368

1.29

-->查看物理读最高的对象 这个部分可以通过如下的方式查询。排查表FILES_CONTROL的时候,发现sql列表中的一个对应的sql语句走了全表扫描,这个表本来数据量就有好几百万,走全表扫描还是可以完全避免的。

Segments by Physical Reads

Owner

Tablespace Name

Object Name

Subobject Name

Obj. Type

Physical Reads

%Total

APPO

DATAS01

STEP_INST

TABLE

10,101,327

25.38

APPO

DATAS01

FILES_CONTROL

TABLE

2,042,467

5.13

APPO

DATAS01

ACCOUNT

TABLE

920,202

2.31

APPO

DATAM01

DOCUMENT

P120_C10

TABLE PARTITION

905,729

2.28

通过如上的方式也确实能够发现不少的问题。也需要互相的印证。毕竟数据是表象,能够结合实际的情况进行调优,从业务上,系统级调优,自己也能一定程度上解放自己。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-10-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据库新发现

Oracle诊断案例-Job任务停止执行[最终版]

Last Updated: Friday, 2004-11-26 9:48 Eygle

14030
来自专栏杨建荣的学习笔记

备库归档删除策略失效的问题分析 (r7笔记第6天)

最近碰到了一个有些奇怪的问题,自己当时排查问题时间紧,没有细细琢磨,今天抽空看了下,终于发现了端倪。 首先是在早晨收到了报警邮件,报警邮件内容如下: ZABBI...

43380
来自专栏数据库新发现

在Mac上通过Docker部署Oracle Database 12.2版本

Oracle 已经宣布支持了Docker部署,这也让我们在Mac上部署 Oracle 数据库有了多一个选择,这是我的第一个Docker应用,非常简便快速的就完...

42160
来自专栏数据库新发现

Oracle诊断案例-Job任务停止执行

Last Updated: Saturday, 2004-11-20 12:47 Eygle

9020
来自专栏杨建荣的学习笔记

通过shell脚本快速定位active session问题(r4笔记第65天)

如果你得到反馈,数据库突然间性能下降了好多,希望你能够尽快的定位出问题来,有一些思路和方法可以参考。分别从数据库层面,系统层面来定位,但是个人感觉而言还是不够快...

36350
来自专栏杨建荣的学习笔记

一个oracle蠕虫病毒 (r4笔记第60天)

关于计算机病毒,说起来内容就很丰富了,但是第一次听到关于oracle中的病毒时,却感觉很新鲜。这是一个蠕虫病毒,距离现在已经有10年了,但是现在看起来还是能够借...

26330
来自专栏杨建荣的学习笔记

通过shell脚本抓取awr报告中的问题sql(r6笔记第78天)

awr报告中的sql明细部分基本必看的部分,尤其是SQL Order by Elapsed time这个部分,能够很清晰的看到哪些sql语句占用了较多的DB t...

30730
来自专栏数据库新发现

Linux上配置Unix ODBC连接Oracle数据库

Oracle10g前,Oracle并不提供UNIX/Linux下的ODBC驱动,用的最为广泛的是UnixOdbc,UnixOdbc的配置不算复杂,但是如果不顺利...

18620
来自专栏杨建荣的学习笔记

使用impdp不当导致的数据丢失问题(r5笔记第1天)

今天有个朋友问我们一个问题,说他在使用了impdp导入数据的时候,使用了TABLE_EXISTS_ACTION=REPLACE这个选项,结果现在数据都给覆盖了。...

37150
来自专栏数据和云

触类旁通:那些关于 TBL$OR$IDX$PART$NUM 的诡异案例和知识

你是否留意过数据库中有一个奇怪的函数 TBL$OR$IDX$PART$NUM ,你是否留意过很多场景下都出现过它的身影?

15940

扫码关注云+社区

领取腾讯云代金券