ADDM报告分析

1.第一部分：数据库概要信息
开头是数据库概要信息。

（1）首先是数据库名称、dbid等信息：
Database DB Id Instance Inst Num Startup Time Release RAC ~~~~~~~~ ----------- ------------ -------- --------------- ----------- --- 1808102524 fantlam 1 27-Sep-11 23:46 10.2.0.1.0 NO
Host Name: localhost.locald Num CPUs: 1 Phys Memory
(MB): 0
~~~~
（2）接下来是数据库采样时段信息，记录了数据库采样的时间，以及采样点数，这部分信息对report来说十分重要。

Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------- Begin Snap: 11 28-Sep-11 01:01:04 17 4.9
End Snap: 21 28-Sep-11 01:49:01 16 6.8
Elapsed: 47.95 (mins)
（3）Cache信息，列举了数据库的内存分配信息，从Oracle9i开始，主要SGA参数可以进行动态调整，所以此处的Cache信息来自采样结束时刻：
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 92M 96M Std Block Size: 8K Shared Pool Size: 56M 52M Log Buffer: 2,859K
2.第二部分：负载概要信息
接下来报表输出的是数据库的负载概要信息，这些信息分别通过每秒和每事务形式展现。

每秒和每事务的负载越高，那也意味着数据库的压力越大。

我们可以通过报告获取数据库负载变化的趋势。

Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 1,711.07 17,003.78
Logical reads: 52.87 525.40
Block changes: 5.53 54.94
Physical reads: 0.11 1.13
Physical writes: 0.67 6.65
User calls: 0.10 1.00
Parses: 3.85 38.29
Hard parses: 0.45 4.49
Sorts: 2.47 24.58
Logons: 0.03 0.32
Executes: 8.27 82.18
Transactions: 0.10
% Blocks changed per Read: 10.46 Recursive Call %: 99.89
Rollback per transaction %: 0.00 Rows per Sort: 8.31
这部分信息来自v$sysstat视图收集的统计信息。

通过前后比较，得出在报告时段数据库的负载变化。

例如这里的redo size就代表在起始采样点和结束采样点之间，数据库生成的redo大小。

（1）SYSDIF函数。

Statspack中的数据差值都是通过一个内部函数sysdif来获得。

这个函数的内容和算法从spcpkg.sql文件中找到。

（2）Redo size信息
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 1,711.07 17,003.78 对于这个采样，数据库每秒产生了大约1.67KB（1,711.07/1024）的redo信息，每个事务平均产生了16.6KB（17,003.78/1024）左右的重做信息。

Redo size信息还可以从报告后面的Instance Activity stats信息中获得。

Redo size就是数据库操作产生的日志量（Redo log）的大小，单位是Byte，如果单位时间内数据库产生的Redo非常多，那么就意味着LGWR要非常频繁地将Redo Log Buffer
中的数据写出到Redo Log File上来，而这又意味着Redo Log File的I/O写入将会很频繁，也就可能导致I/O竞争和忙碌。

3、逻辑读信息。

负载概要接下来显示的逻辑读（Logical Reads）信息非常重要：
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Logical reads: 52.87 525.40
逻辑读是指以任何模式进行数据块读取的逻辑读请求次数。

逻辑读是一个派生的统计数据，计算公式如下：
Logical reads = db_block_gets + consistent_gets
逻辑读代表了数据库读取的繁忙程度。

每秒大量的逻辑读，不管对I/O还是buffer的竞争都可能会非常的激烈。

根据逻辑读，结合物理读信息，可以进一步获取数据库系统的详细信息：
Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Logical reads: 52.87 525.40
Block changes: 5.53 54.94
Physical reads: 0.11 1.13
从上面数据可以看到，物理读是0.11，也就是说仅有(0.11/52.87)0.2%左右的逻辑读引发了物理读。

如果物理读得比例过高，那么系统的性能将会有问题。

4、其他信息。

概要中还包括一些重要的信息。

Block changes代表采样阶段Block修改信息。

Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Block changes: 5.53 54.94
Block changes数据来自v$sysstat表中db_block_changes。

SQL解析信息：
Load Profile Per Second Per Transaction
Parses: 3.85 38.29
Hard parses: 0.45 4.49
Parses代表数据库在采样阶段的总得分析次数。

Hard Parses代表硬解析的数量。

这2个数据来自report中Instance Activity Stats部分。

% Blocks changed per Read：代表逻辑读导致的Block变化百分比。

% Blocks changed per Read: 10.46。

该报告中，有10.46%的逻辑读设计数据块变更。

这个数据来源：
round（Block changes）/Logical reads
Rollback per transaction %：代表平均事务回滚率。

计算公式：Round（User rollback/（User commits + User rollbacks,4）*100%
对于回滚率，User rollbacks和transaction rollbacks的区别：
通常情况下，User rollbacks比transaction rollbacks偏大。

因为即使不执行事务，仅发出rollback操作，User rollbacks也会增长。

所以回滚率精确的计算方式为：
Round（User rollback/（User commits + transaction rollbacks,4）*100%。

通过概要信息，能总体看出数据库运行的一个情况。