上一篇文章提到的那些个工具，主要侧重点在于实时监控，而在我看来，实时监控只是一个监控工具的一个职责而已。就如Linux上的collectl或者nmon一样，我们还需要对这些历史性能数据进行保存，以便于过后进行分析。而且，这也是一个不可或缺的功能，毕竟，DBA不会也不可能24小时盯着屏幕，DBA做的主要事情应该是对历史数据进行分析，从而更好的认识数据库的工作状态。

监控工具方面，也有很多实现这方面需求的软件。记得anySQL.net上面就有一个类似的监控工具。通过收集v$sysstat和v$session的数据，再利用图表的方式进行分析。这应该是这类软件的共性。

但有一个”工具”值得大提特提，那就是Oracle自身的AWR。AWR默认一个小时对系统做一次快照，这些快照其实就是难得的历史性能数据，Oracle自带的AWR报告，主要是基于两个快照间的分析，因此只能得到一些孤立的数值。如果我们能够更进一步，实现对所有快照数据的分析，我们就能清晰地了解系统过去一段时间（默认AWR保留7天）的工作负载的特征曲线，各种重要指标的变化曲线。我想，这些曲线对于DBA或者决策层而言都是极其有价值的。

对这些曲线进行部分展示的，就是Enterprise Manager了。在Performance这个Tab里面，可以选择按Historical浏览的方式。这其实就是对AWR Repository里的数据进行查询。不过EM只提供对一天时间跨度的drill down，所提供的曲线也比较有限，归纳起来，11g里EM提供的主要曲线有：

1. Average Active Sessions – 7 Day View
2. Host: Runnable Processes  – 1 Day
3. Average Active Sessions – 1 Day
4. Logon/Transaction Rate – 1 Day
5. Physical Reads/Redo Size Rate – 1 Day
6. Latency For Synchronous Single Block Reads – 1 Day
7. I/O Megabytes per Second by I/O Function – 1 Day
8. I/O Request per Second by I/O Function – 1 Day
9. Sessions of Parallel Execution – 1 Day
10. Active Sessions of Services – 1 Day

网络上实现类似功能的软件好象不多(知道的朋友请多comment一下)，不过，碰巧也找到了一个，叫做ONDATAPERF。通过用户上传一系列的Statspack或者AWR报告，最后据说会产生一个类似这个链接的ONDATAPERF report。这个报告里面的图表看起来还是很酷的，随便抓一个ASH的例子。

当然，唯一的缺点是这是一个付费服务。

其实，要自己实现类似的功能或者更全面的图表也不是很难的一件事情。可以考虑参考nmon的Analyser，做一个专门针对AWR Repository的Analayser出来。这应该是挺有意义，挺有先驱性的一件事情。要真有这个工具，说不定可以和这个ONDATAPERF 竞争一番呢!

写了Linux上的监控与分析工具之后，写写Oracle上相应的监控与分析工具还是挺有意思的，一方面可以更加完整，一方面可以进行横向对比。

Linux上的性能数据一般都来自于/proc文件系统，而Oracle则是来自于V$视图。因此，所有的Oracle监控工具的实现都万变不离V$ 视图。而这些个视图里面，最重要的应推v$sysstat。里面记录着Instance一级的各个统计数据的当前值，例如CPU利用情况，逻辑读，Redo Size等等。10g后有了另一个重要的视图，叫v$active_session_history,通过它可以容易地得知当前Instance的活动状态，主要是各个时刻系统都在等待哪些事件，通过对这些等待事件和相应等待次数的统计，就可以清晰地了解系统的历史工作负载特征和压力情况。如果想获取当前正在执行的SQL，则可查询v$sql视图。如果想获取当前SQL的执行计划，则可调用dbms_xplan.display_cursor。从这方面讲，每一个DBA都具备着写一个Oracle的监控工具的能力。它应该比写一个Linux的监控工具来得容易简单得多。

如果对监控工具做下分类的话，可以分成两类，一类是基于文本模式的，一类是基于GUI模式的。大部分DBA都自己收集了一些很常见的监控脚本，我想可以把这一类归为基于文本模式的工具。文本模式的好处在于轻量级，反应速度快，比较适合在shell模式下和sqlplus协同工作。大部分DBA可能也比较习惯这个模式，包括我在内。

GUI模式用得较多的工具应该是Toad。很不错的一个工具，用它来监控sessions，session正在执行的语句，session的等待事件是我最常用的一个功能。

也有一些后起之秀，有个工具也许值得一提，叫做DB Optimizer。最主要的是这个产品的主要参与者：参与了10g EM里的Performance Page的重新设计的Kyle Hailey。以一个截图做为结尾吧:

11g里面有个很有用的新特性，对数据透视图的支持。

简单而言，它可以实现宽表和窄表之间的转化。举一个例子，有一张表记录了全校所有班级所有学生的成绩(A,B,C,D,E)，现在想统计每个班级里每个分数级别对应的学生人数。当然，一个SQL就可以实现：

SELECT class, score, count(*) FROM score_table
GROUP BY class, score;

结果的格式如下：

班级      分数 人数
一年一班     A  10
一年一班     B  16
一年一班     C  16
一年一班     D  16
一年一班     E  16
一年二班     A  15
一年二班     B  14
一年二班     C  15
一年二班     D  14
一年二班     E  15

不过，很多人更想要下面的格式

班级        A    B   C   D   E
一年一班   10   16  16  16  16
一年二班   15   14  15  14  15

第二种格式显然简单明了多了。

用Oracle的新语法，可以实现如下

SELECT *
FROM
(
SELECT class,score,count(*) cnt
FROM score_table
GROUP BY class,score
)
pivot
(
sum(cnt) FOR score IN ('A','B','C','D','E')
)
;

一个更实用的场合是对ASH(active session history)数据的处理上。

一般而言，我们需要一段时间内Top 10的wait event，并掌握其在每个时间片(例如10 seconds)里的分布。这些信息可以通过下面的SQL进行获取:

SELECT
    to_char(to_date(trunc(to_char(sample_time,'SSSSS')/10)*10,'SSSSS'),'hh24:mi:ss') start_time
  , decode(ash.session_state,'ON CPU','ON CPU',ash.event)     event
  , count(1)/10 total
FROM
   v$active_session_history ash
WHERE
          sample_time > sysdate-1/24
GROUP BY  trunc(to_char(sample_time,'SSSSS')/10)
       ,  decode(ash.session_state,'ON CPU','ON CPU',ash.event)
;

同样的，我们更习惯将这个结果进行倒置。这同样可以通过pivot来实现:

SELECT * FROM
(SELECT
    to_char(to_date(trunc(to_char(sample_time,'SSSSS')/10)*10,'SSSSS'),'hh24:mi:ss') start_time
  , decode(ash.session_state,'ON CPU','ON CPU',ash.event)     event
  , count(1)/10 total
FROM
   v$active_session_history ash
WHERE
          sample_time >  sysdate-1/24
GROUP BY  trunc(to_char(sample_time,'SSSSS')/10)
       ,  decode(ash.session_state,'ON CPU','ON CPU',ash.event)
) ash
pivot (sum(total) FOR event IN ('ON CPU' AS TOP1,'PX Deq: Slave Session Stats' AS TOP2))
ORDER BY 1;

下面是一个ASH的例子，系统的工作状态已经一目了然了！

TOP   EVENT
----- ----------------------------------------------------------------
TOP1  cell smart table scan
TOP2  ASM file metadata operation
TOP3  control file sequential read
TOP4  ON CPU
TOP5  enq: XL - fault extent map
TOP6  DFS lock handle
TOP7  cell single block physical read
TOP8  reliable message
TOP9  read by other session
TOP10 latch: shared pool

TIME      TOP1  TOP2  TOP3  TOP4  TOP5  TOP6  TOP7  TOP8  TOP9 TOP10
-------- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
00:30:50                       1
00:31:30
00:31:40
00:31:50
00:32:10
00:32:30
00:32:50                       1
00:34:10
00:34:30                       1
00:34:40
00:35:10                       1
00:35:40                       1
00:37:50    16    34     5     9     2           1    14     3     9
00:38:00   296    95     7     9     3           6     1     6
00:38:10   478   133    15     4    17           7           1
00:38:20   543    71    21     6     8           7           5
00:38:30   531    81    13     2    14           9     1     2
00:38:40   600    30    17     4     2     1     2
00:38:50   592    36    16     4     5    10     1
00:39:00   609    20    12     6          10           4
00:39:10   620    14    13     4     2    10
00:39:20   628     5    10     4          10     1
00:39:30   248     7     4                 4           4