Oracle-AWR报告指标全解析.pdf

风武九天

746

62页

21次

2021-02-03

5墨值下载

@?/rdbms/admin/awrddrpt AWR比对报告

@?/rdbms/admin/awrgrpt RAC 全局AWR

自动生成AWR HTML报告：

http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql

1、报告总结

WORKLOAD REPOSITORY report for

DB Name DB Id Instance Inst Num Startup Time Release RAC

------------ ----------- ------------ -------- --------------- ----------- ---

MAC 2629627371 askmaclean.com 1 22-Jan-13 16:49 11.2.0.3.0 YES

Host Name Platform CPUs Cores Sockets Memory(GB)

---------------- -------------------------------- ---- ----- ------- ----------

MAC10 AIX-Based Systems (64-bit) 128 32 320.00

Snap Id Snap Time Sessions Curs/Sess

--------- ------------------- -------- ---------

Begin Snap: 5853 23-Jan-13 15:00:56 3,520 1.8

End Snap: 5854 23-Jan-13 15:30:41 3,765 1.9

Elapsed: 29.75 (mins)

DB Time: 7,633.76 (mins)

Elapsed 为该AWR性能报告的时间跨度(自然时间的跨度，例如前一个快照snapshot是4点生成的，后一个快照snapshot是6点生成的，则若使用@?/rdbms/admin/awrrpt 脚本中

指定这2个快照的话，那么其elapsed = (6-4)=2 个小时)，一个AWR性能报告至少需要2个AWR snapshot性能快照才能生成 ( 注意这2个快照时间实例不能重启过，否则指定这2个

快照生成AWR性能报告会报错)，AWR性能报告中的指标往往是后一个快照和前一个快照的指标的delta，这是因为累计值并不能反映某段时间内的系统workload。

DB TIME= 所有前台session花费在database调用上的总和时间：

注意是前台进程foreground sessions

包括CPU时间、IO Time、和其他一系列非空闲等待时间，别忘了cpu on queue time

DB TIME 不等于响应时间，DB TIME高了未必响应慢，DB TIME低了未必响应快

DB Time描绘了数据库总体负载，但要和elapsed time逝去时间结合其他来。

Average Active Session AAS= DB time/Elapsed Time

DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 负载一般

DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 负载很轻

DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系统hang了吧？

DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue

如果仅有2个逻辑CPU，而2个session在60分钟都没等待事件，一直跑在CPU上，那么：

DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120

AAS = 120/60=2 正好等于OS load 2。

如果有3个session都100%仅消耗CPU，那么总有一个要wait on queue

DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins

AAS= (120+ 60)/60=3 主机load 亦为3，此时vmstat 看waiting for run time

真实世界中？ DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor pin S on X + latch : xxx + db file sequential read + ……….. 阿猫阿狗

1-1 内存参数大小

Cache Sizes Begin End

~~~~~~~~~~~ ---------- ----------

Buffer Cache: 49,152M 49,152M Std Block Size: 8K

Shared Pool Size: 13,312M 13,312M Log Buffer: 334,848K

内存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)

小内存有小内存的问题，大内存有大内存的麻烦！ ORA-04031???!!

Buffer cache和shared pool size的 begin/end值在ASMM、AMM和11gR2 MSMM下可是会动的哦！

这里说 shared pool一直收缩，则在shrink过程中一些row cache 对象被lock住可能导致前台row cache lock等解析等待，最好别让shared pool shrink。如果这里shared pool

一直在grow，那说明shared pool原有大小不足以满足需求(可能是大量硬解析)，结合下文的解析信息和SGA breakdown来一起诊断问题。

1-2 Load Profile

Load Profile Per Second Per Transaction Per Exec Per Call

~~~~~~~~~~~~ --------------- --------------- ---------- ----------

DB Time(s): 256.6 0.2 0.07 0.03

DB CPU(s): 3.7 0.0 0.00 0.00

Redo size: 1,020,943.0 826.5

Logical reads: 196,888.0 159.4

Block changes: 6,339.4 5.1

Physical reads: 5,076.7 4.1

Physical writes: 379.2 0.3

User calls: 10,157.4 8.2

Parses: 204.0 0.2

Hard parses: 0.9 0.0

W/A MB processed: 5.0 0.0

Logons: 1.7 0.0

Executes: 3,936.6 3.2

Rollbacks: 1,126.3 0.9

Transactions: 1,235.3

% Blocks changed per Read: 53.49 Recursive Call %: 98.04

Rollback per transaction %: 36.57 Rows per Sort: 73.70

指标指标含义

redo size

单位 bytes，redo size可以用来估量update/insert/delete的频率，大的redo size往往对lgwr写日

志，和arch归档造成I/O压力， Per Transaction可以用来分辨是大量小事务，还是少量大事

务。如上例每秒redo 约1MB ，每个事务800 字节，符合OLTP特征

Logical Read

单位次数*块数，相当于 “人*次”，如上例 196,888 * db_block_size=1538MB/s ，逻辑读耗

CPU，主频和CPU核数都很重要，逻辑读高则DB CPU往往高，也往往可以看到latch: cache

buffer chains等待。大量OLTP系统(例如siebel)可以高达几十乃至上百Gbytes。

Block changes 单位次数*块数，描绘数据变化频率

单位次数*块数，如上例 5076 * 8k = 39MB/s，物理读消耗IO读，体现在IOPS和吞吐量等不同纬

of 62

5墨值下载

关注

评论