Menu
Woocommerce Menu

二、安装步骤,oracle性能优化之awr分析

0 Comment

–//从这里也相互验证.前面2个占了48.37,41.31.

‘Data’ columns suffixed with M,G,T,P are in multiples of 1024 other
columns suffixed with K,M,G,T,P are in multiples of 1000
Ordered by (Data Read + Write) desc for each function

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

一、软件包

perl-DBI-1.52-1.fc6.i386.rpm

DBD-mysql-4.014.tar.gz

mysqlreport-3.5.zip

二、安装步骤

  1. Rmp –ivh perl-DBI-1.52-1.fc6.i386.rpm

  2. Tar zxvf DBD-mysql-4.014.tar.gz

  3. Cd DBD-mysql-4.014.tar.gz

  4. perl Makefile.PL –mysql_config=/usr/local/mysql/bin/mysql_config

  5. make

  6. make test

  7. make install

  8. unzip mysqlreport-3.5.zip

  9. cd mysqlreport-3.5

  10. cp mysqlreport /usr/local/mysql/bin

  11. ./mysqlreport –user=root –password

  12. Mysql 性能监控情况如下

  13. MySQL 5.0.27-log uptime 0 0:13:32 Thu Jun 10 11:22:11 2010

14.

  1. __ Key
    _________________________________________________________________

  2. Buffer used 14.00k of 16.00M %Used: 0.09

  3. Current 1.86M %Usage: 11.60

  4. Write hit 0.00%

  5. Read hit 99.04%

20.

  1. __ Questions
    ___________________________________________________________

  2. Total 787 1.0/s

  3. COM_QUIT 315 0.4/s %Total: 40.03

  4. DMS 306 0.4/s 38.88

  5. Com_ 203 0.2/s 25.79

  6. -Unknown 37 0.0/s 4.70

  7. Slow 10 s 0 0/s 0.00 %DMS: 0.00 Log: OFF

  8. DMS 306 0.4/s 38.88

  9. SELECT 285 0.4/s 36.21 93.14

  10. UPDATE 21 0.0/s 2.67 6.86

  11. REPLACE 0 0/s 0.00 0.00

  12. DELETE 0 0/s 0.00 0.00

  13. INSERT 0 0/s 0.00 0.00

  14. Com_ 203 0.2/s 25.79

  15. show_fields 200 0.2/s 25.41

  16. show_variab 1 0.0/s 0.13

  17. show_status 1 0.0/s 0.13

38.

  1. __ SELECT and Sort
    _____________________________________________________

  2. Scan 370 0.5/s %SELECT: 129.82

  3. Range 82 0.1/s 28.77

  4. Full join 0 0/s 0.00

  5. Range check 0 0/s 0.00

  6. Full rng join 0 0/s 0.00

  7. Sort scan 87 0.1/s

  8. Sort range 0 0/s

  9. Sort mrg pass 0 0/s

48.

  1. __ Table Locks
    _________________________________________________________

  2. Waited 0 0/s %Total: 0.00

  3. Immediate 419 0.5/s

52.

  1. __ Tables
    ______________________________________________________________

  2. Open 20 of 64 %Cache: 31.25

  3. Opened 26 0.0/s

56.

  1. __ Connections
    _________________________________________________________

  2. Max used 2 of 100 %Max: 2.00

  3. Total 317 0.4/s

60.

  1. __ Created Temp
    ________________________________________________________

  2. Disk table 200 0.2/s

  3. Table 205 0.3/s Size: 32.0M

  4. File 5 0.0/s

65.

  1. __ Threads
    _____________________________________________________________

  2. Running 1 of 1

  3. Cached 0 of 0 %Hit: 0.32

  4. Created 316 0.4/s

  5. Slow 0 0/s

71.

  1. __ Aborted
    _____________________________________________________________

  2. Clients 0 0/s

  3. Connects 37 0.0/s

75.

  1. __ Bytes
    _______________________________________________________________

  2. Sent 3.49M 4.3k/s

  3. Received 80.19k 98.8/s

79.

  1. __ InnoDB Buffer Pool
    __________________________________________________

  2. Usage 320.00k of 8.00M %Used: 3.91

  3. Read hit 95.71%

  4. Pages

  5. Free 492 %Total: 96.09

  6. Data 20 3.91 %Drty: 0.00

  7. Misc 0 0.00

  8. Latched 0 0.00

  9. Reads 303 0.4/s

  10. From file 13 0.0/s 4.29

  11. Ahead Rnd 1 0.0/s

  12. Ahead Sql 0 0/s

  13. Writes 0 0/s

  14. Flushes 0 0/s

  15. Wait Free 0 0/s

95.

  1. __ InnoDB Lock
    _________________________________________________________

  2. Waits 0 0/s

  3. Current 0

  4. Time acquiring

  5. Total 0 ms

  6. Average 0 ms

  7. Max 0 ms

103.

  1. __ InnoDB Data, Pages, Rows
    ____________________________________________

  2. Data

  3. Reads 26 0.0/s

  4. Writes 3 0.0/s

  5. fsync 3 0.0/s

  6. Pending

  7. Reads 0

  8. Writes 0

  9. fsync 0

113.

  1. Pages

  2. Created 0 0/s

  3. Read 20 0.0/s

  4. Written 0 0/s

118.

  1. Rows

  2. Deleted 0 0/s

  3. Inserted 0 0/s

  4. Read 0 0/s

  5. Updated 0 0/s

–//后记:开发修改代码后YF_ZYFYMX从Segments by Physical
Reads消失.上班在看看a.kfrq 的查询范围.

–//201275448*8192/1024/1024/1024/1024 =
1.49961894750595092773,与IOStat by Function/Filetype
summary看到的统计一致.
–//查看IO统计:
IOStat by Function/Filetype summary

二、问题总结及解决方式

    本报告期,系统的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中对索引列进行了范围搜索,则会导致该索引无效会进行全表扫描,反向键索引只对<>\=有效)。
   *

–//最近一段时间,一直在看exdata方面的书籍,我个人的感觉exadata并非善长oltp系统,能通过OLTP获得好处的就算exadata的闪存(也叫
–//智能闪存).当然大部分系统负载类型都是混合型的,但是如果你系统OLTP占的比例越大,使用exadata带来的受益越小.
–//如同你买了一辆豪华平跑车,却跑在乡间的小道上.
–//一次开会,跟一位同行闲聊,我跟他提到我们使用exadata更多的是掩盖应用系统拙劣的设计,拙劣sql语句,保证业务能正常运行.^_^.
–//因为没有exadata,会频繁出现性能问题.

|E-Bytes| Cost (%CPU)| E-Time   |

|   0 | SELECT STATEMENT              |                         |       
|       |   215K(100)|          |
|   1 |  HASH JOIN                    |                         |     19
| 27645 |   215K  (1)| 00:43:02 |
|   2 |   JOIN FILTER CREATE          | :BF0000                 |     19
|   817 |    16   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| EMR_BL_BL01             |    
19 |   817 |    16   (0)| 00:00:01 |
|   4 |     INDEX RANGE SCAN          | I_EMR_BL_BL01_BRBH_CJSJ
|     19 |       |     3   (0)| 00:00:01 |
|   5 |   JOIN FILTER USE             | :BF0000                 |  
3968K|  5343M|   215K  (1)| 00:43:01 |
|   6 |    TABLE ACCESS STORAGE FULL  | EMR_BL03                |  

 

–//还有的问题就是不应该写成NOT EXISTS,注:fy
仅仅有2个取值.而应该写成如下:
AND EXISTS (SELECT  jlxh FROM YF_ZY_LY_UPLOAD WHERE jlxh = a.jlxh AND
fy = 0)
–//这样建立fy建立索引,如果fy=0很少的话,也可以加快查询.但是问题的本质还是前面的查询时间范围太大.
–//要修改必须2个都要,这样效果就很明显了.

Note

   – Warning: basic plan statistics not available. These are only
collected when:
       * hint ‘gather_plan_statistics’ is used for the statement or
       * parameter ‘statistics_level’ is set to ‘ALL’, at session or
system level
35 rows selected.

zzzzz> @ &r/desc XXXXXX_YYY.EMR_BL03
Name  Null?    Type


WDBH  NOT NULL NUMBER(18)
ZYMZ  NOT NULL NUMBER(2)
BLBH  NOT NULL NUMBER(18)
WDLX  NOT NULL NUMBER(4)
WDNR           BLOB

zzzzz> select segment_name,bytes/1024/1024/1024 Gb from
DBA_SEGMENTS where segment_name=’EMR_BL03′;
SEGMENT_NAME                 GB


EMR_BL03             12.2724609

zzzzz> select segment_name,bytes/1024/1024/1024 gb from
dba_segments where segment_name in
(select segment_name from DBA_LOBS where table_name=’EMR_BL03′);
SEGMENT_NAME                           GB


SYS_LOB0000087717C00005$$      102.436523

–//我以前大概测试过我们现在使用的exadata,select /*+ full(a) */
count(*) from big_table a;IO最大吞吐量大约2.5GB/s.
–//(102.436523+12.2724609)/2.5 = 45.88359356,这样非常接近.

–//可以发现这个表存在blob字段,读取数据时访问blob字段时选择直接路径读.而不会出现cell
smart table scan等待事件.
–//真不知道awr报表提示直接路径读1.5T如何得来的,估计像我前面提到那样漏掉类似的sql语句.

–//EMR_BL03存在索引IDX_EMR_BL03_BLBH.字段包括ZYMZ, BLBH,
WDLX.不知道为什么没有选择index skip scan.

3.看看direct path read设计那些数据段:
zzzzz> select event,count(*) from DBA_HIST_ACTIVE_SESS_HISTORY
where sql_id=’crzs1c9pnjqg2′ group by event;
EVENT                                      COUNT(*)


direct path read                                  5

–//5次,取样10秒1次,需要50秒.这样与前面的执行时间基本对上.主要等待事件就是direct
path read.

zzzzz> @ &r/ev_name.sql ‘direct path read’
    EVENT#   EVENT_ID NAME                                    
PARAMETER1           PARAMETER2           PARAMETER3          
WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS




       198 3926164927 direct path read                         file
number          first dba            block cnt              
1740759767           8 User I/O
       199  861319509 direct path read temp                    file
number          first dba            block cnt              
1740759767           8 User I/O

zzzzz> select event,p1,p2,p3,p1text,p2text,p3text from
DBA_HIST_ACTIVE_SESS_HISTORY where sql_id=’crzs1c9pnjqg2′ ;
EVENT            P1       P2   P3 P1TEXT       P2TEXT    P3TEXT


direct path read 56  2562432  128 file number  first dba block cnt
direct path read 59  3122176  128 file number  first dba block cnt
direct path read 59  3729536  128 file number  first dba block cnt
direct path read 60   287744  128 file number  first dba block cnt
direct path read 63    43392  128 file number  first dba block cnt

–//看看对应那些段.
zzzzz> column PARTITION_NAME noprint
zzzzz> @ &r/which_obj 56 2562432
OWNER      SEGMENT_NAME         SEGMENT_TYPE      
TABLESPACE_NAME                 EXTENT_ID    FILE_ID   BLOCK_ID     
BYTES     BLOCKS RELATIVE_FNO




XXXXXX_YYY EMR_BL03             TABLE             
XXXXXX_YYY                            151         56    2556416  
67108864       8192           56

zzzzz> @ &r/which_obj 59 3122176
OWNER      SEGMENT_NAME         SEGMENT_TYPE      
TABLESPACE_NAME                 EXTENT_ID    FILE_ID   BLOCK_ID     
BYTES     BLOCKS RELATIVE_FNO




XXXXXX_YYY EMR_BL03             TABLE             
XXXXXX_YYY                            162         59    3121664  
67108864       8192           59

–//有点小小吃惊,抓取对应的都是表段,没有lob段.有点奇怪.应该有一些lob段.不理解…..

4.问题解决:
–//加入提示很快执行完成:
SELECT /*+ INDEX_SS(EMR_BL03 ) */ XXXXXX_YYY.EMR_BL03.*,
XXXXXX_YYY.EMR_BL_BL01.BLMC
  FROM XXXXXX_YYY.EMR_BL03
  LEFT JOIN XXXXXX_YYY.EMR_BL_BL01
    ON XXXXXX_YYY.EMR_BL03.BLBH    = XXXXXX_YYY.EMR_BL_BL01.BLBH
 WHERE XXXXXX_YYY.EMR_BL_BL01.BRBH = ‘00366441’;

作者:bingjava

–//实际上正是exadata运行太快,我估计存储索引在这里发挥很大作用,导致这样的语句没有出现在awr报表导致这个语句到现在才发现,我
–//甚至估计a.kfrq > TO_DATE(‘2017-09-20’,
‘yyyy-mm-dd’)时间是某个衔接项目的上线时间.开发写这样代码我自己真心很无语..

Segments by Direct Physical Reads

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

Segments by Physical Reads
Total Physical Reads: 36,791,770
Captured Segments account for 93.1% of Total
Owner      Tablespace Name Object Name                Subobject Name
Obj. Type Physical Reads %Total
xxxxxx_yyy xxxxxx_yyy      MS_CF01                                  
TABLE         17,796,271 48.37
xxxxxx_yyy xxxxxx_yyy      YF_ZYFYMX                                
TABLE         15,197,689 41.31
xxxxxx_yyy xxxxxx_yyy     
IDX_ZY_FYMX_FYRQ                          INDEX            642,671
1.75
xxxxxx_zzz xxxxxx_zzz     
I_EMR_BL_BASYSJ_JZHM_XMXH_QZ              INDEX            144,043
0.39
xxxxxx_yyy xxxxxx_yyy      BQ_TJ02                                  
TABLE            101,577 0.28

1.awr报表情况:
Top 10 Foreground Events by Total Wait Time

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块左右。

–//当我拿看到的这些sql_id查询awr报表时,发现这些sql语句根本不出现在awr报表?
–//而我执行如下:
select * from v$active_session_history where sql_id=’&sql_id’ order
by 2 desc;

1 |       |     5   (0)| 00:00:01 |

一、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监控程序导致的。

 

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图