WORKLOAD REPOSITORY report for Oracle

DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间，说明数据库比较空闲。
在79分钟里（其间收集了3次快照数据），数据库耗时11分钟，RDA数据中显示系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利用率只有大约2%（1.4/79）。说明系统压力非常小。
可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
指标公式:
每个CPU耗时:=DB Time / 逻辑cpu个数=11.05/8=1.4
CPU利用率:DB Time / (逻辑cpu个数Elapsed)=11.05/(878.19) *100%=2%
DB time<Elapsed x cpu_count 表明数据库负荷较小
DB time=cpu time+wait time
注解:cpu time+wait time（都是指非后台进程），换句话说，db time就是前端用户进程所花费
经验值: 数据库负载DB Time/(Elapsed * NUM_CPUS) > 80%时，表明存在性能问题,需要分析TOP的等待事件或是SQL ordered by Elapsed Time

Report Summary

Cache Sizes

显示SGA中每个区域的大小（在AMM改变它们之后），可用来与初始参数值比较。
shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。
指标公式:
shared pool=library cache+dictionary cache

Load Profile

显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。
Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。
Logical reads：每秒/每事务逻辑读的块数
Block changes：每秒/每事务修改的块数
Physical reads：每秒/每事务物理读的块数
指标：
Physical reads / Logical reads=68.26/3,521.77=1.9%的逻辑读导致了物理I/O，平均每个事物产生2,974.06（blocks）,这个数字应该越小越好。 Read的單位是block .

Physical writes：每秒/每事务物理写的块数
User calls：每秒/每事务用户call次数
Parses：SQL解析的次数
Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。
Sorts：每秒/每事务的排序次数
Logons：每秒/每事务登录的次数
Executes：每秒/每事务SQL执行次数
Transactions：每秒事务数
Blocks changed per Read：
表示逻辑读用于修改数据块的比例，此数据高，表明DML更新操作的块占整个被操作的(逻辑读)的块的比例高。

Recursive Call：
递归调用占所有操作的比率，表明通过pl/sql来执行的

Rollback per transaction：
每事务的回滚率，例子中85.49值已经非常高，(表示每个事物产生0.85个回滚)，系统存在回滚方面的问题，因为回滚的代价非常昂贵，即平均每1.17（1/0.85）个事务就要产生一次回滚 。 结合前面的transactions 每秒为 1.18个，即每秒会有1.18/1.17 = 1 次回滚。 应该仔细检查系统为何产生如此高的回滚率。
公式：每秒回滚次数=transactions per sencend/(1/Rollback per transaction)=transactions per sencend*Rollback per transaction

Rows per Sort：每次排序的行数
注:
Oracle的硬解析和软解析
提到软解析(soft parse)和硬解析(hard parse)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：
1、语法检查(syntax check)
检查此sql的拼写是否语法。
2、语义检查(semantic check)
诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对sql语句进行解析(parse)
利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。
4、执行sql，返回结果(execute and return)
其中，软、硬解析就发生在第三个过程里。
Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值；
假设存在，则将此sql与cache中的进行比较；
假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。
诚然，如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。
创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。

Instance Efficiency Percentages (Target 100%)

本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
Buffer Nowait表示在内存获得数据的未等待比例。 期望值是100%
buffer hit表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。期望值是100%
Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。
library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要调大shared pool区。
Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。
Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。
Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。
Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。

Shared Pool Statistics

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。
SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

Top 5 Timed Foreground Events

这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如果‘buffer busy wait’是较严重的等待事件，我们应当继续研究报告中Buffer Wait和File/Tablespace IO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。
在这里，log file parallel write是相对比较多的等待，占用了7%的CPU时间。
通常，在没有问题的数据库中，CPU time总是列在第一个。
更多的等待事件，参见本报告 的Wait Events一节。

CPU time : CPU time其实不是真正的等待事件。是衡量CPU是否瓶颈的一个重要指标,
Elapsed Time = CPU Time + Wait Time 。 一般来讲，一个良好的系统，CPU TIME 应该排在TOP 5 TIME Event的最前面，否则，就要进行调整以减少其他的WAIT TIME。 当然这也是相对的， 如果不存在显著的 latch wait 或过高的logical read 等, CPU time 占的比例高才是令人放心的。 也就是说CPU在高效率干活是好事，但是是否因为低效的设置或SQL而消耗CPU时间就需要注意了。
db file sequential read 与 db file scattered read.
这两个事件是出现比较频繁的事件。 他们表明Oracle内核请求从磁盘读取数据块 (到buffer cache中), 他们的区别就是
sequential 是单块读（串行读），而scattered 表示多块读。(和是否全表扫描无关, 只是全表扫描一般表现为多块读) 。 这两个事件描述的是如何将数据块存储到内存中的, 而不是如何从磁盘进行读取。
db file scattered read
一次获取的block被分散在buffer的不连续空间中，通常表示全表扫描过多，可检查应用程序是否合理的使用了索引，数据库是否合理的创建了索引 。 db file scattered read是用来表示顺序读取(例如,全表扫描)。
file sequential read
通常暗示着通过索引获取数据量比较大（比如通过索引进行范围扫描获取表数据百分比过大或者错误的使用索引），多表连接的时候连接顺序不当，hash join时hash_area_size无法容纳hash table 等。db file sequential read是用来表示随机读取(例如,索引扫描)。

深入解析db file sequential read 及 db file scattered read ：
定义
事件名db file sequential read与db file scattered read描述的是如何将数据块存储到内存中的,而不是如何从磁盘进行读取. 如果填充磁盘读取的内容的内存是连续的, 发生的磁盘读就是db file sequential read , 当填充从磁盘读取的数据的内存的连续性无法被保证的时候,发生的磁盘读就是db file scattered read.

db file sequential read
Oracle 为所有的单块读取生成db file sequential read事件（既然是单个，当然是连续的，你可以发现db file sequential read 等待事件的P3参数一般都是1）. Oracle始终将单个数据块存储在单个缓存块(cache buffer)中, 因此单块读取永远不会产生db file scattered read事件. 对于索引块，如果不是快速全索引扫描，一般都是一个一个块读取的，所以说，这个等待事件很多时候都是索引读取引起的。
这一事件通常显示与单个数据块相关的读取操作(如索引读取)。如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表; 或者可能说明不加选择地进行索引。在大多数情况下我们说，通过索引可以更为快速的获取记录，所以对于一个编码规范、调整良好的数据库，这个等待很大是很正常的。但是在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中我们就应该注意，对于这样的查询应该进行避免使用索引扫描。
db file scattered read
db file scattered read 一般都是等待同时读取多个块到内存中。为了性能和更有效的内存空间利用，oracle一般会把这些块分散在内存中。db file scattered read 等待事件的P3参数指出了每次I/O读取的块数。每次I/O读取多少个块，由参数db_file_multiblock_read_count控制。全表扫描或者快速全索引扫描时一般使用的这种读取块的方式，所以，该等待很多时候都是因为全表扫描引起的；在大部分情况下, 全表扫描与快速全索引扫描都会产生一次或多次db file scattered read. 不过, 有时 , 这些扫描只会产生db file sequential read.
因为全表扫描被置于LRU（Least Recently Used，最近最少使用）列表的冷端（cold end），对于频繁访问的较小的数据表，可以选择把他们Cache到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 以及动态性能视图来进行诊断，该视图中记录了长时间（运行时间超过6秒的）运行的事物，可能很多是全表扫描操作（不管怎样，这部分信息都是值得我们注意的）。

latch free
latch是一种轻量级的锁。一般来说，latch由三种内存元素组成：pid（进程id），内存地址和内存长度。Latch保证对共享数据结构的排它性访问，以此来保证内存结构的完整性不受到损坏。在多个会话同时修改或者检视(inspect)sga中同一个内存结构时，必须串行化访问以保证sga中数据结构的完整性。
Latch只是用来保护sga中的内存结构。对数据库中的对象的保护，使用的lock而不是latch。Oracle sga中有许多latch，用来保护sga中各种内存结构不会因为并发访问而损坏。常见的Latch Free等待事件是由于热块 (buffer cache中的latch争用) 及未使用绑定变量(shared pool中的latch争用) 导致的。
最常见的Latch集中于Buffer Cache的竞争和Shared Pool的竞争。和Buffer Cache相关的主要Latch竞争有cache buffers chains和cache buffers lru chain，和Shared Pool相关的主要Latch竞争有Shared Pool Latch和Library Cache Latch等。 Buffer Cache的Latch竞争经常是由于热点块竞争或低效的SQL语句引起； Shared Pool的Latch竞争通常是由于SQL的硬解析引起。过大的共享池可能导致shared pool latch 争用(9i之前的版本)；
当latch在系统范围内的等待时间比较显著时，你可以通过vlatch中的sleeps列来发现争用显著的latch：Selectname,gets,misses,immediategets,immediatemisses,sleepsfromvlatch中的sleeps列来发现争用显著的latch：Selectname,gets,misses,immediategets,immediatemisses,sleepsfromvlatch order by sleeps desc ;

buffer busy waits
发生条件：
block正被读入缓冲区或者已经在缓冲区正被其他session修改, 一个会话尝试去pin 住它，这时当前block已经被pin住，就发生了竞争，产生一个buffer busy waits, 该值不应该大于1% 。可以查看vwaitstat看到大概的bufferbusywaits分布。解决办法：出现此情况通常可能通过几种方式调整：增大databuffer,增加freelist，减小pctused,增加回滚段数目，增大initrans,考虑使用LMT+ASSM,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小).该等待事件表示正在等待一个以非共享方式使用的缓冲区，或者表示当前正在被读入buffercache。一般来说BufferBusyWait不应大于1waitstat看到大概的bufferbusywaits分布。解决办法：出现此情况通常可能通过几种方式调整：增大databuffer,增加freelist，减小pctused,增加回滚段数目，增大initrans,考虑使用LMT+ASSM,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小).该等待事件表示正在等待一个以非共享方式使用的缓冲区，或者表示当前正在被读入buffercache。一般来说BufferBusyWait不应大于1WAITSTAT)，看一下等待是否位于段头(Segment Header)。 如果是，可以考虑增加自由列表(freelist，对于Oracle8i DMT)或者增加freelist groups(在很多时候这个调整是立竿见影的，在8.1.6及以后版本，动态修改feelists需要设置COMPATIBLE至少为8.1.6)， Oracle9i或以后可以使用ASSM .
alter table xxx storage(freelists n);

Main Report

Report Summary
Wait Events Statistics
SQL Statistics
Instance Activity Statistics
IO Stats
Buffer Pool Statistics
Advisory Statistics
Wait Statistics
Undo Statistics
Latch Statistics
Segment Statistics
Dictionary Cache Statistics
Library Cache Statistics
Memory Statistics
Streams Statistics
Resource Limit Statistics
Shared Server Statistics
init.ora Parameters

Back to Top

Wait Events Statistics

Time Model Statistics
Operating System Statistics
Operating System Statistics - Detail
Foreground Wait Class
Foreground Wait Events
Background Wait Events
Wait Event Histogram
Wait Event Histogram Detail (64 msec to 2 sec)
Wait Event Histogram Detail (4 sec to 2 min)
Wait Event Histogram Detail (4 min to 1 hr)
Service Statistics
Service Wait Class Stats
Back to Top

Time Model Statistics

Total time in database user-calls (DB Time): 84.6s
Statistics including the word “background” measure background process time, and so do not contribute to the DB time statistic
Ordered by % or DB time desc, Statistic name

此节显示了各种类型的数据库处理任务所占用的CPU时间。

Foreground Wait Class

s - second, ms - millisecond - 1000th of a second
ordered by wait time desc, waits desc
%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
Captured Time accounts for 25.1% of Total DB time 84.58 (s)
Total FG Wait Time: 6.99 (s) DB CPU time: 14.27 (s)

Foreground Wait Events

s - second, ms - millisecond - 1000th of a second
Only events with Total Wait Time (s) >= .001 are shown
ordered by wait time desc, waits desc (idle events last)
%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0

db file scattered read
等待事件是当SESSION等待multi-block I/O时发生的，通过是由于full table scans或 index fast full scans。发生过多读操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”节中识别（在其它版本的报告中，可能是别的名称）。如果在OLTP应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。

DB file sequential read
等待意味着发生顺序I/O读等待（通常是单块读取到连续的内存区域中），如果这个等待非常严重，应该使用上一段的方法确定执行读操作的热点SEGMENT，然后通过对大表进行分区以减少I/O量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的sequential read等待。通过在批量应用中，DB file sequential read是很影响性能的事件，总是应当设法避免。

Log File Parallel Write
事件是在等待LGWR进程将REDO记录从LOG 缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的，但LGWR需要等待最后的I/O写到磁盘上才能认为并行写的完成，因此等待时间依赖于OS完成所有请求的时间。如果这个等待比较严重，可以通过将LOG文件移到更快的磁盘上或者条带化磁盘（减少争用）而降低这个等待。

Buffer Busy Waits
事件是在一个SESSION需要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是：1）另一个SESSION正在将数据块读进BUFFER。2）另一个SESSION正在以排它模式占用着这块被请求的BUFFER。可以在“Segments by Buffer Busy Waits”一节中找出发生这种等待的SEGMENT，然后通过使用reverse-key indexes并对热表进行分区而减少这种等待事件。
Log File Sync事件
当用户SESSION执行事务操作（COMMIT或ROLLBACK等）后，会通知 LGWR进程将所需要的所有REDO信息从LOG BUFFER写到LOG文件，在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。减少此等待的方法写Log File Parallel Write事件的处理。
Enqueue Waits
是串行访问本地资源的本锁，表明正在等待一个被其它SESSION（一个或多个）以排它模式锁住的资源。减少这种等待的方法依赖于生产等待的锁类型。导致Enqueue等待的主要锁类型有三种：TX（事务锁）, TM D（ML锁）和ST（空间管理锁）

Background Wait Events

ordered by wait time desc, waits desc (idle events last)
Only events with Total Wait Time (s) >= .001 are shown
%Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0

Operating System Statistics

*TIME statistic values are diffed. All others display actual values. End Value is displayed if different
ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name

NUM_LCPUS： 如果显示0，是因为没有设置LPARS
NUM_VCPUS： 同上。
AVG_BUSY_TIME： BUSY_TIME / NUM_CPUS
AVG_IDLE_TIME： IDLE_TIME / NUM_CPUS
AVG_IOWAIT_TIME： IOWAIT_TIME / NUM_CPUS
AVG_SYS_TIME： SYS_TIME / NUM_CPUS
AVG_USER_TIME： USER_TIME / NUM_CPUSar o
BUSY_TIME： time equiv of %usr+%sys in sar output
IDLE_TIME： time equiv of %idle in sar
IOWAIT_TIME： time equiv of %wio in sar
SYS_TIME： time equiv of %sys in sar
USER_TIME： time equiv of %usr in sar
LOAD： 未知
OS_CPU_WAIT_TIME： supposedly time waiting on run queues
RSRC_MGR_CPU_WAIT_TIME： time waited coz of resource manager
PHYSICAL_MEMORY_BYTES： total memory in use supposedly
NUM_CPUS： number of CPUs reported by OS
NUM_CPU_CORES： number of CPU sockets on motherboard
总的elapsed time也可以用以公式计算：
BUSY_TIME + IDLE_TIME + IOWAIT TIME
或：SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME
（因为BUSY_TIME = SYS_TIME+USER_TIME）

%User = USER_TIME/(BUSY_TIME+IDLE_TIME)100
%Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)100
%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100
ELAPSED_TIME=(BUSY_TIME+IDLE_TIME)/cpu count/100
Total DB CPU = DB CPU + background cpu time
% Total CPU= (DB CPU + background cpu time)/(BUSY_TIME+IDLE_TIME)/cpu count/100

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
Back to Top
本节按各种资源分别列出对资源消耗最严重的SQL语句，并显示它们所占统计期内全部资源的比例，这给出我们调优指南。例如在一个系统中，CPU资源是系统性能瓶颈所在，那么优化buffer gets最多的SQL语句将获得最大效果。在一个I/O等待是最严重事件的系统中，调优的目标应该是physical IOs最多的SQL语句。
在STATSPACK报告中，没有完整的SQL语句，可使用报告中的Hash Value通过下面语句从数据库中查到：
select sql_text
from stats$sqltext
where hash_value = &hash_value
order by piece;

SQL ordered by Elapsed Time

Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100
%Total - Elapsed Time as a percentage of Total DB time
%CPU - CPU Time as a percentage of Elapsed Time
%IO - User I/O Time as a percentage of Elapsed Time
Captured SQL account for 309.1% of Total DB Time (s): 85
Captured PL/SQL account for 60.7% of Total DB Time (s): 85

Elapsed Time（S）：SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。ElapsedTime= CPUTime+Wait Time
CPU Time（s）： 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。
Executions:SQL语句在监控范围内的执行次数总计。
Elap per Exec（s）：执行一次SQL的平均时间。单位时间为秒。
% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。
SQL ID:SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。
SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。
SQL Text:简单的sql提示，详细的需要点击SQL ID。

Complete List of SQL Text

wan

完整的AWR报告参考附件：awrrpt_1_757_776.html
本文档整理过程参考url：http://www.cnblogs.com/HondaHsu/archive/2012/09/13/2682910.html

本文由 知点 首发于【知点网（http://www.zhidnet.com）】未经允许不得以任何方式转载，违者必将追究法律责任。