图片 4

Oracle的AWR报告分析

* 定义:awr报告是oracle
10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告。如何分析:*
在看awr报告的时候,我们并不需要知道所有性能指标的含义,就可以判断出问题的所在,这些性能指标其实代表了oracle内部实现,对oracle理解的越深,在看awr报告的时候,对数据库性能的判断也会越准确*
在看性能指标的时候,心里先要明白,数据库出现性能问题,一般都在三个地方,io,内存,cpu,这三个又是息息相关的(ps:我们先假设这个三个地方都没有物理上的故障),当io负载增大时,肯定需要更多的内存来存放,同时也需要cpu花费更多的时间来过滤这些数据,相反,cpu时间花费多的话,有可能是解析sql语句,也可能是过滤太多的数据,到不一定是和io或内存有关系了*
当我们把一条sql送到数据库去执行的时候,我们要知道,什么时候用到cpu,什么时候用到内存,什么时候用到io1.
cpu:解析sql语句,尝试多个执行计划,最后生成一个数据库认为是比较好的执行计划,不一定是最优的,因为关联表太多的时候,数据库并不会穷举所有的执行计划,这会消耗太多的时间,oracle怎么就知道这条数据时你要,另一个就不是你要的呢,这是需要cpu来过滤的
2.
内存:sql语句和执行计划都需要在内存保留一段时间,还有取到的数据,根据lru算法也会尽量在内存中保留,在执行sql语句过程中,各种表之间的连接,排序等操作也要占用内存
Oracle的AWR报告分析。3.
io:如果需要的数据在内存中没有,则需要到磁盘中去取,就会用到物理io了,还有表之间的连接数据太多,以及排序等操作内存放不下的时候,也需要用到临时表空间,也就用到物理io了这里有一点说明的是,虽然oracle占用了8G的内存,但pga一般只占8G的20%,对于专用服务器模式,每次执行sql语句,表数据的运算等操作,都在pga中进行的,也就是说只能用1.6G左右的内存,如果多个用户都执行
多表关联,而且表数据又多,再加上关联不当的话,内存就成为瓶颈了,所有优化sql很重要的一点就是,减少逻辑读和物理读

oracle性能优化之awr分析

如何生成awr报告:* 1:登陆对应的数据库服务器
2:找到oracle磁盘空间(d:oracleproduct10.2.0db_1RDBMSAdmin)
3:执行cmd-cd d:回车
4: cd d:oracleproduct10.2.0db_1RDBMSAdmin 回车
5:sqlplus 用户名/密码@服务连接名(例:sqlplus
carmot_esz_1/carmot@igrp)
6:执行@awrrpt.sql 回车第一步输入类型: html
第二步输入天数:
天数自定义(如1,代表当天,如果2,代表今天和昨天。。。)
第三步输入开始值与结束值:(你可以看到上面列出的数据,snap值)
这个值输入开始,与结束
第四步输入导出表的名称:名称自定义 回车
第五步,由程序自动导完。第六:到d:oracleproduct10.2.0db_1RDBMSAdmin
目录下。找到刚才生成的文件。 XXXX.LST文件具体分析过程: *
在分析awr报告之前,首先要确定我们的系统是属于oltp,还是olap(数据库在安装的时候,选择的时候,会有一个选项,是选择oltp,还是olap)
对于不同的系统,性能指标的侧重点是不一样的,比如,library hit和buffer
hit,在olap系统中几乎可以忽略这俩个性能指标,而在oltp系统中,这俩个指标就非常关键了*
首先要看俩个时间
Elapsed: 240.00 (mins)
表明采样时间是240分钟,任何数据都要通过这个时间来衡量,离开了这个采样时间,任何数据都毫无疑义
DB Time: 92,537.95 (mins)
表明用户操作花费的时候,包括cpu时间喝等待时间,也许有人会觉得奇怪,为什么在采样的240分钟过程中,用户操作时间竟然有92537分钟呢,远远超过了
采样时间,原因是awr报告是一个数据的集合,比如在一分钟之内,一个用户等待了30秒,那么10个用户就等待了300秒,对于cpu的话,一个cpu处理了30秒,16个cpu就是4800秒,这些时间都是以累积的方式记录在awr报告中的。再看sessions,可以看出连接数非常多*
为了对数据库有个整体的认识,先看下面的性能指标

作者:bingjava

图片 1 1.
Buffer Nowait
说明在从内存取数据的时候,没有经历等待的比例,期望值是100%

 

  1. Buffer Hit
    说明从内存取数据的时候,buffer的命中率的比例,期望值是100%,但100%并不代表性能就好,因为这只是一个比例而已,举个例子,执行一条
    sql语句,#
    执行计划是需要取10000个数据块,结果内存中还真有这10000个数据块,那么比例是100%,表面上看是性能最高的,还有一个执行计划是需要500
    个数据块,内存中有250个,另外250个需要在物理磁盘中取,
    这种情况下,buffer
    hit是50%,结果呢,第二个执行计划性能才是最高的,所以说100%并不代表性能最好
  2. Library Hit 说明sql在Shared Pool的命中率,期望值是100%
  3. Execute to Parse
    说明解析sql和执行sql之间的比例,越高越好,说明一次解析,到处执行,如果parse多,execute少的话,还会出现负数,因为计算公式是100*(1-parse/execute)
  4. Parse CPU to Parse Elapsd
    说明在解析sql语句过程中,cpu占整个的解析时间比例,,期望值是100%,说明没有产生等待,需要说明的是,即使有硬解析,只要cpu没有出现性能问题,也是可以容忍的,比较硬解析也有它的好处的
  5. Redo NoWait 说明在产生日志的时候,没有产生等待,期望值是100%
  6. Soft Parse
    说明软解析的比例,期望值是100%,有一点要说明的是,不要单方面的追求软解析的高比例,而去绑定变量,要看性能的瓶颈在哪里
  7. Latch Hit
    说明latch的命中率,期望值是100%,latch类似锁,是一种内存锁,但只会产生等待,不会产生阻塞,和lock还是有区别的,latch是在并发的情况下产生的
  8. Non-Parse CPU
    说明非解析cpu的比例,越高越好,用100减去这个比例,可以看出解析sql所花费的cpu,100-99.30=0.7,说明花费在解析sql上的cpu很少*
    结合Time Model Statistics

最近某证券公司系统在业务期间系统运行缓慢,初步排查怀疑是数据库存在性能问题,因此导出了oracle的awr报告进行分析,在此进行记录。

图片 2 
可以看出,在整个sql执行时间(sql execute elapsed
time)时间为5552019秒中,解析时间(parse time
elapsed)用了36秒,硬解析时间(hard parse elapsed
time)用了34秒虽然硬解析时间占了整个解析时间的绝大部分,但解析时间是花的很少的,所以可以判断出,sql的解析没有成为性能的瓶颈,进一步推测,sql在获取数据的过程中遇到了瓶 颈*
继续看Top 5 Timed
Events,从这里可以看出等待时间在前五位的是什么事件,基本上就可以判断出性能瓶颈在什么地方

导致系统的性能问题有很多,比如内存、cpu占用率过高,网络延迟、系统存储io瓶颈、还有程序方面的代码逻辑、性能低下的sql语句等等,这里主要从awr的角度说明如何通过awr的报告来定位问题。

图片 3 1.
buffer busy waits
说明在获取数据的过程中,频繁的产生等待事件,很有可能产生了热点块,也就是说,很多会话都去读取同样的数据块,这一事件等待了5627394次,总共等待了5322924秒,平均等待时间为946毫秒,而且频率也是最高的,有95.9%,等待类别是并发
这里有一个概念:oracle操作的最小单位是块,当一个会话要修改这个块中的一条记录,会读取整个块,如果另一个会话要修改的数据也正好在这个块中,虽然这俩个

一、awr报告分析及问题定位

DB Name 

DB Id 

Instance 

Inst num 

Release 

RAC 

Host 

**DB

1527139216 

**DB

10.2.0.5.0

NO 

p3-**DB

 

Snap Id 

Snap Time 

Sessions 

Cursors/Session 

Begin Snap: 

16021 

01-Mar-16 10:00:34 

213 

2.4 

End Snap: 

16022 

01-Mar-16 11:00:36 

213 

2.3 

Elapsed: 

  

60.04 (mins) 

  

  

DB Time: 

  

176.32 (mins) 

  

  

关键项说明:

DB
TIME:代表了此统计期间的数据库负载,是所有前台session花费在database调用上的总和时间(包括CPU时间、IO
Time、和其他一系列非空闲等待时间)。如果 DB Time 接近于 Elapsed
Time*cpu 数,表明数据库比较忙,cpu
负载也许比较大。这时很有可能是因为资源争用导致等待事件的结果,可以去 top
5 等待事件分析原因。

Operating
System Statistics

Statistic 

Total 

BUSY_TIME 

1,037,128 

IDLE_TIME 

10,487,927 

IOWAIT_TIME 

19,061

NICE_TIME 

316 

SYS_TIME 

132,552 

USER_TIME 

882,792 

LOAD 

RSRC_MGR_CPU_WAIT_TIME 

VM_IN_BYTES 

1,274,466,304 

VM_OUT_BYTES 

2,174,697,472 

PHYSICAL_MEMORY_BYTES 

33,712,308,224 

NUM_CPUS 

32 

NUM_CPU_SOCKETS 

 

 

从以上信息可知:

单数据库实例,非集群部署模式;2个物理cpu(NUM_CPU_SOCKETS=2),32个逻辑cpu(NUM_CPUS=32)。

cpu利用率为:DB Time /(Elapsed* NUM_CPUS)=176/(60*32) *100%=9.2%

cpu的负载处于正常水平。

Load Profile

 

Per Second 

Per Transaction 

Redo size: 

89,367.47 

21,227.40 

Logical reads: 

105,600.68 

25,083.26 

Block changes: 

458.93 

109.01 

Physical reads:

27,716.84 

6,583.56 

Physical writes: 

30.80 

7.32 

User calls: 

3,675.70 

873.09 

Parses: 

324.60 

77.10 

Hard parses: 

14.13 

3.36 

Sorts: 

44.47 

10.56 

Logons: 

1.69 

0.40 

Executes: 

340.07 

80.78 

Transactions: 

4.21 

  

 

% Blocks changed per Read: 

0.43 

Recursive Call %:

16.91 

Rollback per transaction %: 

0.09 

Rows per Sort: 

397.30 

 

Redosize:每秒产生的日志大小(单位字节),可标志数据变更频率,大的redosize往往对lgwr写日志,和arch归档造成I/O压力,也有可能造成logbuffer堵塞从而产生相关的等待事件。很繁忙的系统中日志生成量可能达到几百k,甚至几M。在Top
5 Timed
Events中未发现log方面的等待事件,说明redo生成的频率属于正常范围。

 

Logical reads:
从内存中读取数据的次数(次数*块数),每秒钟逻辑读数据量:105,600.68*8k=825m

Physical
reads:当从内存中未都到数据时则从硬盘上读取数据,每秒物理读数据量:27,716.84 *8k=216m

Physical reads / Logical
reads=27,716.84/105,600.68=26%,有26%的逻辑读导致了物理io。因此此处的物理io可能是系统的性能瓶颈(具体需在后面的
top 5中进行分析)。

Instance
Efficiency Percentages (Target 100%)

Buffer Nowait %: 

98.73 

Redo NoWait %: 

100.00 

Buffer Hit %:

73.77 

In-memory Sort %: 

100.00 

Library Hit %: 

89.85 

Soft Parse %: 

95.65 

Execute to Parse %: 

4.55 

Latch Hit %: 

96.92 

Parse CPU to Parse Elapsd %: 

95.60 

% Non-Parse CPU: 

96.41 

 

buffer
hit:表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个
值本身更重要。对于一般的 OLTP 系统,通常应在 95%以上。否则应考虑加大
db_cache_size, 但是大量的非选择的索引也会造成该值很高(大量的 db file
sequential read)。

Latch
Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch
Hit>99%,否则意味着Shared Pool
latch争用,可能由于未共享的SQL,或者Library
Cache太小,可使用绑定变更或调大Shared Pool解决。

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

 

Parse CPU to Parse
Elapsd:该指标反映了快照内解析CPU时间和总的解析时间的比值(Parse
CPU Time/ Parse Elapsed Time); 若该指标水平很低,那么说明在整个解析过程中
实际在CPU上运算的时间很短,而主要的解析时间都耗费在各种其他非空闲的等待事件上了,此值越高越好。

 

Shared Pool Statistics

 

Begin 

End 

Memory Usage %:

56.42 

55.58 

% SQL with executions>1: 

54.12 

49.23 

% Memory for SQL w/exec>1: 

49.88 

48.29 

SQL with executions

:代表了sql重复执行的比例,本报告中是54%,是比较低的,说明存在sql硬编码的情况,同时上面的Execute to
Parse也只有4.55%,也说明了sql解析的重用率低。

内存利用率为55%左右,属于正常情况。

 

Top 5
Timed Events

业务11:00-12:00期间:

Event 

Waits 

Time(s) 

Avg Wait(ms) 

% Total Call Time 

Wait Class 

CPU time 

  

10,028 

  

94.8 

  

db file scattered read 

6,943,920 

644 

6.1 

User I/O 

read by other session 

4,837,558 

578 

5.5 

User I/O 

CSS initialization 

13 

65 

4,967 

.6 

Other 

db file sequential read

512,027 

58 

.6 

User I/O 

业务15:00-16:00期间

Event 

Waits 

Time(s) 

Avg
Wait(ms)
 

%
Total Call Time
 

Wait
Class
 

CPU
time 

  

2,569 

  

95.8 

  

SQL*Net
more data to client 

1,150,806 

233 

8.7 

Network 

db file
scattered read 

1,381,500 

136 

5.1 

User
I/O 

CSS
initialization

13 

63 

4,878 

2.4 

Other 

db file
sequential read 

42,488 

30 

1.1 

User
I/O 

 

db file scattered read:

表明Oracle内核请求从磁盘读取多个数据块到buffer cache中,

这种情况通常显示与全表扫描相关的等待。当数据库进行全表扫时,基于性能的考虑,
数据会分散读入Buffer
Cache。如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或者没有创建合适的索引。

read by other
session:

Oracle
操作的最小单位是块(Block),当对数据块做修改时,其他的会话将被阻止对这个数据块上的数据做修改,但是可以以一致性的方式读取这个数据块(from
undo)。当前的用户修改完这个数据块后,将会立即释放掉加在这个数据块上的排他锁,这样另一个会话就可以继续修改它,这种加锁的机制叫Latch。当一个会话将数据块都到内存中时,其它的会话同时也请求了这个数据块,就导致被等待的会话出现read
by other session。而当前会话一般是db file scattered read或db file
sequential read。

从本次awr报告中都发现,db file scattered read、db file sequential
read、read by other
session这几个事件的等待次数很高,因此可以判断当前业务场景存在热点块竞争问题。

 

SQL*Net more data to client:

    当服务器端有太多的数据需要发给客户端时,可能会产生此等待事件,也可能由于网络问题导致服务器无法及时地将信息或者处理结果发送给客户端,
同样会产生这个等待。在15:00--16:00业务期间此等待事件相对较高,从SQL*Net看并不像应用程序(应用程序是JDBC
Thin Client),可能是第三方的oracle监控程序导致的。

 

 

 

  1. 会话修改的记录不一样,也会产生等待direct path write temp和direct path
    read temp 说明用到了临时表空间,那我们再看一下Tablespace IO
    Stats图片 4 各项指标都是非常高的,再根据上面的In-memory
    Sort是100%,没有产生磁盘排序,也就在排序的时候没有用到临时表空间,进一步推测,多个session,每个session执行的sql语句中多表关联,产生了很多中间数据,pga内存中放不下,
    用到了临时表空间,也有可能是用到了lob字段,在用lob字段的时候,也会用到临时表*
    继续看SQL Statistics
    根据buffer busy
    waits等待次数,时间,频率都是最高的,我们重点看逻辑读,物理读,和执行时间最长的sql,把排在前几位的拿出来优化
    优化的原则为降低物理读,逻辑读,sql语句中的子操作执行次数尽量少,在看oracle估计出来的执行计划是看不出子操作的执行次数的,要看运行时的执行计划*
    有兴趣的话还可以看一下Segment Statistics
    列出了用到的索引和表的使用情况,从这里也能看出索引和表的使用频率*
    也可以看一下Load Profile
    里面列出了每秒,每个事务所产生的日志,逻辑读和物理读等指标

File IO Stats

Tablespace 

Filename 

Reads 

Av
Reads/s
 

Av
Rd(ms)
 

Av
Blks/Rd
 

Writes 

Av
Writes/s
 

Buffer
Waits
 

Av Buf
Wt(ms)
 

JSZ35_TBS 

*tbs01.dbf

2,635,786 

732 

0.10 

14.88 

4,032 

2,016,907 

0.12 

JSZ35_TBS 

*tbs02.dbf

2,730,384 

758 

0.09 

12.89 

10,420 

1,679,836 

0.12 

JSZ35_TBS 

*tbs03.dbf

2,084,937 

579 

0.08 

12.19 

9,183 

1,141,265 

0.13 

以上数据文件,平均每秒被读700多次,平均每秒读取的数据块为14块左右。

Tablespace IO Stats

Tablespace 

Reads 

Av
Reads/s

Av
Rd(ms)
 

Av
Blks/Rd
 

Writes 

Av
Writes/s
 

Buffer
Waits
 

Av Buf
Wt(ms)
 

JSZ35_TBS 

1,420,317 

394 

0.11 

14.73 

9,502 

113 

2.30 

 

Segments by Buffer Busy Waits

Owner 

Tablespace
Name
 

Object
Name
 

Subobject
Name
 

Obj.
Type
 

Buffer
Busy Waits
 

% of
Capture
 

JSZ35 

JSZ35_TBS

TF_SUBJECTPRICE_TMP 

  

TABLE 

30 

32.26 

JSZ35 

JSZ35_TBS 

IND_T_*LOG

  

INDEX 

21 

22.58 

JSZ35 

JSZ35_TBS 

PK_T_**_TMP

  

INDEX 

15 

16.13 

JSZ35 

JSZ35_TBS 

T_***HER

CHER_P2016 

TABLE
PARTITION 

9.68 

JSZ35 

JSZ35_TBS 

IND_T_***HER

  

INDEX 

 

其它业务时间段:

Owner 

Tablespace
Name
 

Object
Name
 

Subobject
Name
 

Obj.
Type
 

Buffer
Busy Waits
 

% of
Capture
 

JSZ35 

JSZ35_TBS 

IND_T_*LOG

  

INDEX 

60 

68.18 

JSZ35 

JSZ35_TBS 

IND_T_***SED

  

INDEX 

20 

22.73 

 

JSZ35 

JSZ35_TBS 

TF_SUBJECTPRICE_TMP 

 

TABLE 

18 

17.65 

JSZ35 

JSZ35_TBS

IND_T_***HER

 

INDEX 

6.86 

 

Segments by Physical Reads

Owner 

Tablespace
Name
 

Object
Name
 

Subobject
Name
 

Obj.
Type
 

Physical
Reads
 

%Total 

JSZ35 

JSZ35_TBS 

T_***NCE

ANCE_P2015 

TABLE
PARTITION 

81,573,441 

81.70 

JSZ35 

JSZ35_TBS 

T_***NCE

ANCE_P2016 

TABLE
PARTITION

12,884,029 

12.90 

JSZ35 

JSZ35_TBS 

T_***CE

RICE_P2016 

TABLE
PARTITION 

3,471,341 

3.48 

热点数据块主要是T_***NCE、T_***CE引起。

数据块热点问题io等待的主要对象为:

T_***LOG、TF_SUBJECTPRICE_TMP、TS_PROCESSED、TF_SUBJECTPRICE_TMP、T_***NCE、T_***CE

可结合SQL ordered by CPU Time(最耗时的sql)、SQL ordered by
Gets(逻辑读最多的sql)、SQL ordered by
Reads(物理读最多的sql)来定位具体的sql语句。

 

二、问题总结及解决方式

    本报告期,系统的cpu、内存表现正常,造成系统性能问题的主要原因为物理读过多,产生io等待;同时由于相关业务表存在频繁的并发访问现象(逻辑读较多)且性能较差而导致了数据块竞争问题。逻辑读是消耗cpu的,而物理读是消耗io的,这也说明了系统的大部分时间都消耗在io等待上,所以cpu相对空闲。

优化方案主要包括应用层的优化和oracle数据库的优化:

    一、应用层的优化目标主要在于降低对数据库的访问频率、合理有效使用索引(合理有效使用索引,需通过对sql语句的执行计划进行分析和调优):

  1. T_***LOG可能存在较频繁的插入数据操作,可采用以下方式减少对数据库的提交操作:

将此表的单条insert的操作改为批量入库提交的方式(比例100条记录入库一次)。

  1. T_***_TMP可能存在读写混合的场景,需根据业务分析是否有优化的空间。

  1. T_***NCE、T_***CE、T_A***T,关于此表的相关访问应该是最需要优化的了,需优化的sql语句为(比如索引是否合理):

关键sql语句:SELECT /*+ LEADING ("A3" "A2" "A1") PQ_DISTRIBUTE ("A1", BROADCAST, NONE)USE_NL ("A1") FULL ("A1") PQ_DISTRIBUTE ("A2", BROADCAST, NONE)USE_NL ("A2") FULL ("A2") FULL ("A3") */ "A3"."FSETCODE", "A2"."FDATE", "A1"."FSETNAME", SUM(CASE WHEN "A3"."FACCTATTR" LIKE ‘??±????%’ THEN "A2"."FENDBAL" ELSE 0 END ), SUM(CASE WHEN "A3"."FACCTATTR" LIKE ‘???±£??%’ THEN "A2"."FENDBAL" ELSE 0 END ) FROM "T_A***T" "A3", "T_***NCE" "A2", "T_AS**T" "A1" WHERE "A3"."FACCTDETAIL"=1 AND "A2"."FDATE"=TO_DATE(TO_CHAR(:1), ‘yyyy-mm-dd’) AND ("A3"."FACCTATTR" LIKE ‘??±????%’ OR "A3"."FACCTATTR" LIKE ‘???±£??’) AND "A3"."FSETCODE"="A1"."FSETCODE" AND "A3"."FSETCODE"="A2"."FSETCODE" AND "A3"."FACCTCODE"="A2"."FACCTCODE" GROUP BY "A3"."FSETCODE", "A2"."FDATE", "A1"."FSETNAME"

select sum(NVL(fbacccredit, 0)) as fje from(select fsetcode, facctcode, fbacccredit from T_***NCE where fsetcode=:1 and fdate=:2 ) a left join T_A***T b on a.fsetcode = b.fsetcode and a.facctcode = b.facctcode where b.facctattr like :3 and b.facctdetail=1

select a.fdate, a.fsetcode, a.fzqdm, a.fhqssj, a.fhqpjj, a.fbjsj, a.fsjsj, a.fzdcj, a.fjyzt, a.fjysc, a.fzqlb, a.fsyqx, a.fdatasource, a.fyqfyfx, a.fgzjgly, a.ftpdate from T_***CE a where fsh = 1 and fdate = to_date(‘2016-02-29’, ‘yyyy-MM-dd’) and a.fsetcode = 0 union select a.fdate, a.fsetcode, a.fzqdm, a.fhqssj, a.fhqpjj, a.fbjsj, a.fsjsj, a.fzdcj, a.fjyzt, a.fjysc, a.fzqlb, a.fsyqx, a.fdatasource, a.fyqfyfx, a.fgzjgly, a.ftpdate from (select fdate, fsetcode, fzqdm, fhqssj, fhqpjj, fbjsj, fsjsj, fzdcj, fjyzt, fjysc, fzqlb, fsyqx, fdatasource, fyqfyfx, fgzjgly, ftpdate, fsh from T_***CE where fzqlb = ‘JJ’) a right join (select FDate, FZqdm, fjysc From T_***CE where fsh = 1 and fdate = to_date(‘2016-02-26’, ‘yyyy-MM-dd’) and fsetcode = 0 and fzqlb = ‘JJ’) b on b.FDate = a.FDate and a.FZqdm = b.FZqdm and a.fjysc = b.fjysc and a.fsh = 1 where fsetcode = 0 and a.fjysc = ‘Y’

关键的sql语句:其中上面的第一条语句执行情况,SQL ordered by
Elapsed Time:

Elapsed Time
(s)
 

CPU
Time (s)
 

Executions 

Elap
per Exec (s)
 

%
Total DB Time

SQL
Id
 

SQL
Module
 

SQL
Text
 

3,519 

3,601 

  

33.26 

f089ggtmuxsnu

oracle@p3tgbmsdb1
(TNS V1-V3) 

SELECT
/*+ LEADING… 

1,305 

1,086 

158 

8.26 

12.34 

7m0bfdfskwgcc

JDBC
Thin Client 

select
sum(…

该语句执行了3600秒(即整个快照期)都还未执行完成,该语句是三张表的关联统计查询,oracle自动对其进行并行查询,可能由于此三张表(T_A***T、T_***NCE、T_AS**T)的数据量较大,尤其是T_A***T的数据量较大时更是影响性能,采用并行查询后反而导致了对io的争用,降低了性能。

4、全表扫描问题

大表在一小时内发生了822次全表扫描,如果表的数据比较大则对性能有很大影响。小表每秒中有28次全表扫描,需重点优化以上3条sql语句。

table
scans (direct read)

0.00 

0.00 

table
scans (long tables) 

822 

0.23 

0.07 

table
scans (rowid ranges) 

0.00 

0.00 

table
scans (short tables) 

102,749 

28.52 

8.27 

total
number of times SMON posted 

22 

0.01 

 

 

 

二、oracle优化

     
1、合理设置DB_FILE_MULTIBLOCK_READ_COUNT,此参数控制在多数据块读时一次读入数据块的次数。适当增加这个参数大小,能够提高多数据块操作(如全表扫描)的IO效率。

2、可以考虑对以上热点表重建索引、分区表等方式来降低该数据段上的IO负荷,将历史数据进行分离(比如根据业务情况将2015年之前的数据转移到另外的备份库中)。

3、因Buffer Hit只有73%,可根据Buffer Pool Advisory调整buffer
pool大小为:16g。

4、将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增大pctfree值
,扩大数据分布,减少竞争)。

5、属于index
block的表(如T_
**SED、T_***_TMP),应该考虑重建索引、分割索引或使用反向键索引。关于反向键索引需根据sql语句查询特点进行有选择使用(如果在where中对索引列进行了范围搜索,则会导致该索引无效会进行全表扫描,反向键索引只对<>=有效)。
   *