下面是我的一个试验：

第一阶段是准备工作：

1. 创建一个用户

2. 查看一下系统启动和目前的时间，我用的是虚拟机，所以从10号就没关机，是从13:33:16开始启动的

3. 先创建一个表

4. 第一次插入数据后，有76166条记录

5. 不断的向里面插入数据，最后达到了1218656 * 2条数据，即有2437312数据。

6. 然后执行select * from my_objects1 where owner = ‘WP’的语句，因为没有索引，我期望这条语句能慢一些，这样我就能收集到数据了。

因为这个my_objects1是没有索引的，我的主要目的是看看ADDM能否分析出我这个SQL语句没有建索引，然后能否给出我一个建议来。

准备从这里开始分析，所以我先建立一个当前的快照，不想去分析这个准备工作的工作。

可以从dba_hist_snapshot中看到目前的快照信息，也就是从129开始的

现在开始做一次ADDM分析

我在收集的时候是加有spool t.txt; 最后再执行spool off;的，所以这个报告放到文件 t.txt文件中

从这个报告中可以看到，在128到129这两个快照中，一共的：Total database time was 115 seconds。

竟然说我没有问题！

原因何在呢？因为我的数据库内存是1G，整个虚拟机是3G，我的电脑是6G，表很多内容还是缓存在内存中的；同时因为这个时间差有115秒，而执行这个语句其实也就几秒种，所以ADDM认为这个还是可以接受的，虽然我知道它有问题，但是显然ADDM仅以DB TIME去判断是犯了错误。

这位我再测试一下，一来不使用绑定变量，二来全部全表扫描，并且快照间隙再小了一点，然后分析这个报表。

declare

v_num number;

begin

for i in 1..1000000 loop

select cnt into v_num from (select count(*) as cnt from my_objects1 where DATA_OBJECT_ID = i);

end loop;

end;

/

这次呢我从132的快照开始即：014919开始执行，一直没停过，在外面吃点东西，回来已经024903分了，这次这个执行是消耗了绝大多数时间了。

这次我们可以看到，终于有报告出来了！ 总的时间是778秒 ， 778 / 60 = 12.9分钟。可是我们是从014919 ~ 022403 这期间大约有34分钟呢，为什么只有12.9分钟呢？因为是DB TIME,不是墙上时钟的

先看看报告的总体框架：

1. analysis period --> 分析的周期，即快照的时间

2. analysis target --> 分析的目标，即数据库的概要信息，这里可以看到，我分析ANALYZE_DB，但是它却是按实例去分析的

3. activity during the analysis period --> 总的活跃性

4. summary of Findings --> 总的介绍，这里看到有2个问题，一个是SQL问题，一个是IO问题

l Findings and Recommendations

l Finding 1

l Finding 2

l Additional Information

从这个Finding 1:中可以看到问题的根原是由SQL引起的，接下来就是recommendation 1:建议我们使用sql tunning去调试一下我们的SQL语句：

action: 使用sql tunning去调试一下，它将我们这个sql的sql_id给了我们，这样就容易做了

接下来有5个Rationale（原理），这些原因就是为了解释数据库为什么要我们去做SQL TUNING，也就是说它要我们做是有科学依据的。

一：这条SQL占据了太多的CPU,IO；

二：将SQL解析完后，100%时间在执行，0%用于解析，0%用于PL/SQL,0%用于JAVA。其实不是0%用于解析，而是可能是0.01%，数据库一看是不到1%就省略了

三：这条SQL语句执行了197次，平均是3.8秒。因为我在写这个PL/SQL块时，一开始有错误，所以调试时多执行了几次，本质上不是这次执行这么多

四：对wp.my_objects1表进行了全表扫描，这个对象的ID是76906（可以从dba_objects中查看到这对象信息了）

五：列出了我当时执行的PL/SQL块，看看写的是什么

因为不断的消耗IO中，所以finding 2给出了IO的问题，这里和finding 1不同，因为这里给了3个ACTION，却只有1个rationale

三个ACTION是：使用SEGMENT ADVISOR；查一下在my_objects1上有什么应用逻辑处理；看一下TOP SQL的那个 SQL_ID问题

一个rationale： 在这个对象上有199次全表扫描，一共有6，925，051次物理读

最后是一些额外信息，在这里我们看到wait class “Application，commit,concurrency,confiuration,network”,CPU,connect,hard parse都没有消耗足够的数据库时间，所以在消耗这些类的活动都没有列出来。

了解完整个报告之后，再这篇文章的开始看，发现写了太多的废话，可以说根本用不着再看了，这篇文章只要知道怎样去收集数据库分析模式，实例模式；知道怎样去显示报告；知道怎样去看这个报告就可以了。其它的废话不用去看了

最后再看一下：