Oracle最重要的九大性能视图

摘要：Oracle数据库的性能优化一直以来都是DBA关注的焦点，在不同的版本中，Oracle都提供了相关的工具用于数据库的性能诊断，事实上这些工具都是通过对数据库中记录性能数据的视图进行不断采样来获得Statspack的元数据，而这些数据正是使用工具分析性能的基础。这篇文章我们将会介绍数据库中最重要的性能视图。

我曾经在Blog上提到为一个DBA朋友提出一个问题：列举你认为最重要的9个动态性能视图（view）。为每个视图写一篇文章（不少于5页Word文档），说明从这个视图你能够获得哪些信息。最后再写一篇文章（不少于20页Word文档），说明联合这些视图你能够获得哪些重要的数据库信息，并辅助数据库优化与诊断。

对于这个问题的本意，我当时这样解释：其实文章长短我并非在意，关键是你是否真的对这些知识作了思考，并且能够把这些知识运用到实践中去。

首先要自己思考，看看自己能想到哪些方面，然后再去参考别人的经验，看差距在什么地方。比较然后学习，研究然后深入。同样地，最忌不作思考，直接去找别人的答案。这就如同我们解数学题一样，如果你偷看了答案，那么就会局限你的思路，很难再做出独立的思考和创新。

这样思考、比较、学习、总结，如是数番，我不相信技术得不到提高。这个世界并不复杂，最怕你从不认真。其实这题目、这文章是做给自己看的，而不是别人。作为一个DBA，我们要能够时常停下来给自己提问，看自己对某些问题能够把握到什么样的细节。

我的这个问题后来被某些公司的朋友采用到DBA面试中去，参加过面试的朋友又来问我答案。实际上我提出的只是一个命题，答案肯定因人而异，而且这个问题的答案也无所谓对错。但是通过答案我们的确可以看出一个人对数据库的认识和理解，看出他的侧重点，看出他的知识面。进而，面试者可以通过你的回答进行更为深入的提问，从而来考察你的真实水平。在完善的面试下，真实的技术水平肯定是无法隐瞒的。

好了，在继续读下去之前，请每位读者合上书，找一张纸写出你自己的答案，当作一次面试，看看你对自己的答案是否说得清楚、是否满意？

提出这个命题还有另外一层含义，在很多生产环境中，当出现突发性问题时，也许没有任何工具可以利用，没有Statspack，只有sql*plus可以使用，我曾经向很多应试者提问：此时你应该怎样做？

有一点是毫无疑问的，你需要去查询动态性能视图，获得系统运行状况的概貌，找出系统问题的原因所在。

在前面部分中，我们介绍Statspack时已经提到了很多数据库的动态性能视图，现在我们可以把这些视图进行一点归类总结和扩充。

1．和session相关的主要视图v$session->v$session_wait

通过这两个视图，可以快速得到当前连接session的状态，如果数据库正在经历诸如等待、竞争、锁定等问题，通过这两个视图就可以找到性能问题的原因，以及正在导致这些问题的session。

2．和Session级统计信息相关的视图有v$sesstat -> v$sysstat

通过v$sesstat可以对当前连接运行的session信息进行获取和分析；通过v$sysstat则可以对数据库启动以来的运行状况获得整体印象。

3．和等待事件相关的主要视图v$session_event->v$system_event

这里需要对v$session_wait和v$session_event视图进行一点区别和说明。v$session_event视图记录当前连接session的等待事件信息，这些等待事件是session生命周期内的各种等待事件的累计，比如查询当前session的累积等待：

该视图记录不同等待事件的等待时间、等待次数等信息。

而v$session_wait记录的是活动session当前正在等待的资源信息，是实时信息的记录，v$session_wait的实时等待结束之后才能被记入v$session_event。简单粗略一点来描述，v$session_wait是“现在”，v$session_event是“曾经”：

当然v$session_wait和v$session_event不仅仅是“现在”和“曾经”这么简单，v$session_wait视图记录的信息更为复杂和全面，在这个视图中，Oracle通过额外的参数（P1，P2，P3）将等待事件具体等待的资源等信息呈现出来，对于不同的事件，这3个参数具有不同的含义，比如对于db file scattered read等待，P1就代表文件号，P2代表数据块号，P3则代表块数（P代表Parameter）。

这些信息可以通过另外一个视图查询获得：

Statspack相关信息记录的数据表包括：

注意到，在Oracle9i中，v$session和v$session_wait的信息并没有被Statspack收集，而v$system_event视图记录的又是累积信息，这也就意味着我们不能对session的历史进行追踪，也就无法得知一个等待是哪一个session如何以及何时引发的，针对这一情况，Oracle 10g中开始增强。

最后列举一下我对这个问题的答案：

1. v$session+ v$session_wait = Oracle10gv$session；

2. v$sysstat；

3. v$system_event；

4. v$process；

5. v$sql；

6. v$sqltext；

7. v$lock；

8. v$latch_children；

9. v$bh。

这是我的答案，除了数据库等待、统计信息等，我还关心进程信息（v$process）、闩（v$latch_children）竞争信息、锁（v$lock）等待信息、SQL（v$sql，v$sqltext）信息、Buffer信息（v$bh），当然还有很多重要视图值得关注，但是如果只能列出9个视图？你会怎样排列呢？

Statspack最主要的优势在于能够持续地收集这些信息，从而能够对数据库的变化趋势给出数据分析，但是毕竟Statspack还要DBA手工去安装、定时规划、数据维护等，当一个企业缺少专门的维护人员时，如果出现问题，即使Oracle专家到达现场也无法获得太多的有效信息，为了解决这些问题，Oracle开始尝试将这些工作自动化进行。

关于session信息的增强

虽然v$session_wait记录的信息如此重要，但是这些重要的信息是随session状态变化而变化的，如果希望获得数据库的历史状态及session的历史等待信息等数据，是不可得的，所以很多时候我们很难回答这样的问题：

• 这个系统昨天是什么样子的?

• 今天和昨天相比有什么不同？

• 1个小时前的那次性能下滑是哪个用户引起的？

• 是哪些事件使我们今天用了更多的时间来等待？

你也可能一次又一次地听到OracleSupport这样问：问题出现时系统是怎样的状况？问题出现时系统有哪些等待？你能否重现（reproduce）问题以便我们判断？

很多这样的问题是极其使人恼火的，我们当然不希望问题重现（reproduce）再次引起当机或业务损失，而那些问题看起来分明是不作为的责任推卸。可是事实是，失去了现场和当时的状态以及session的实时信息，也的确很难判断问题的所在。

从Oracle 10g开始，Oracle开始改变这一切。所以说了这么多，我只想更郑重地告诉大家：这一改变是多么得重要。

v$session视图的增强

在Oracle 10g中，Oracle将v$session视图进行了全面增强，现在这个视图被赋予了更多的含义。

首先关于阻塞的信息被加入进来：

BLOCKING_SESSION_STATUS       VARCHAR2(11)

 BLOCKING_INSTANCE                   NUMBER

 BLOCKING_SESSION                     NUMBER

BLOCKING_SESSION记录了造成当前等待session的进程ID，来看一下以下测试，首先在session 1中执行一个更新操作，暂时不提交：

然后另外再开一个session，同样执行更新，此时的更新将处于等待：

SQL> connect eygle/sysdba

Connected.

SQL> update eygle set username='EYGLE';

现在来看看v$session新提供的信息能够帮助我们发现什么：

注意到59号session阻塞了进程90，在以前版本中，这些信息可以通过另外两个视图来查询：

同时Oracle将v$session_wait的信息整合入v$session视图，更简便地，对于等待也可以通过v$session视图获得：

通过SQL查询可以进一步找到阻塞其他session的用户正在执行的操作：

新增v$session_wait_history视图

为了更有效地保留session信息，Oracle 10g新增加了一个v$session_wait_history视图，该视图用以记录活动session的最近10次等待事件。

最近10次的等待信息，受隐含参数 _session_wait_history 控制，其缺省值是10，如果想保留活动会话更多的等待，可以通过修改这个隐含参数来控制。

通过这个视图，可以将v$session_wait延伸，获取更多的相关信息辅助数据库问题诊断。这是Oracle迈出的一小步。

本文摘自《循序渐进-数据库管理优化与备份恢复》