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

v$session视图记录了当前连接Session的信息,这些信息包括用户名、连接主机、Session正在执行的SQL的SQL_ADDRESS、SQL_HASH_VALUE等,非常详尽。v$session_wait则记录了当前连接session正在等待的资源信息。在Oracle 10g中,Oracle将v$session_wait视图的内容合并入v$session视图,使得对于当前session信息的获取更加简便。

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

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

v$sesstat视图记录了session的统计信息,这些统计信息包括诸如session的逻辑数据读取、物理数据读取、排序操作等。v$sesstat收集的信息同时会累积进入v$sysstat视图,v$sysstat视图记录的是整个数据库系统的统计信息。

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

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

v$session_event记录了当前连接session的等待事件,这些信息最终被累积进入v$system_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迈出的一小步。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-03-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Albert陈凯

2018-09-12 构建大型支付系统时学到的分布式体系结构概念构建大型支付系统时学到的分布式体系结构概念

两年前我作为一名拥有后台开发经验的移动端软件工程师入职 Uber,并负责 APP 端支付功能的开发以及重构。后来我进入了工程师管理团队,并独立带领一个团队。由于...

662
来自专栏Kirito的技术分享

浅析项目中的并发(一)

前言 开头扯两句,最近项目略忙,一堆零散的东西要做,没那么多时间维护文章了。又迷上了吃鸡,大雾spring security系列投入了我不少时间,但总体收获也颇...

3409
来自专栏恰同学骚年

谈谈对于企业级系统架构的理解

在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层;而对于一个新手来说,从...

602
来自专栏Java架构师学习

多研究些架构,少谈些框架——一名阿里架构师的笔记

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为...

3338
来自专栏无题

高并发商品详情页构建

* 主要思路: 1、数据变更还是通过MQ通知; 2、数据异构Worker得到通知,然后按照一些维度进行数据存储,存储到数据异构JIMDB集群(JIMDB:Re...

3546
来自专栏开源优测

JMeter定时器06

前言 在默认情况下,jmeter发送每个请求之间是没有延时的,如果采用默认方式,如果线程数足够大,瞬间就会将服务器压死。再则在实际的业务过程中,请求之间是有一定...

3276
来自专栏瓜大三哥

时序分析中的基本概念和术语

1.建立保持时间 ? 2.四种时序路径 ? 第一类时序路径:从设备A的时钟到FPGA的第一级寄存器的数据输入端口 第二类时序路径:两个同步原件之间的路径,...

2058
来自专栏杨建荣的学习笔记

数据刷新中的并行改进(r5笔记第72天)

昨天按照计划进行了系统升级,多多少少还是碰到了一些问题。 有一个问题不算紧急,但是也在计划之中需要进行调优和改进。是关于数据的复制刷新的使用。为了更加清楚的描述...

2957
来自专栏存储

你真的很熟分布式和事务吗?

微吐槽 hello,world. 不想了,我等码农,还是看看怎么来处理分布式系统中的事务这个老大难吧! 本文略长,读者需要有一定耐心,如果你是高级码农或者架构师...

1849
来自专栏杨建荣的学习笔记

远程协助解决重建索引的危机问题 (r8笔记第80天)

最近在工作忙碌之余也帮几位网友查看了几个问题,有一个问题让我印象挺深,其实也可以分享出来作为一些参考,问题之外还是有一些值得借鉴的地方。 首先是在周末的一...

3094

扫描关注云+社区