好了,在继续读下去之前,请每位读者合上书,找一张纸写出你自己的答案,当作一次面试,看看你对自己的答案是否说得清楚、是否满意? 提出这个命题还有另外一层含义,在很多生产环境中,当出现突发性问题时,也许没有任何工具可以利用,没有Statspack,只有sql*plus可以使用,我曾经向很多应试者提问:此时你应该怎样做? 有一点是毫无疑问的,你需要去查询动态性能视图,获得系统运行状况的概貌,找出系统问题的原因所在。 在前面部分中,我们介绍Statspack时已经提到了很多数据库的动态性能视图,现在我们可以把这些视图进行一点归类总结和扩充。 1.和session相关的主要视图v$session->v$session_waitv$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$sysstatv$sesstat视图记录了session的统计信息,这些统计信息包括诸如session的逻辑数据读取、物理数据读取、排序操作等。v$sesstat收集的信息同时会累积进入v$sysstat视图,v$sysstat视图记录的是整个数据库系统的统计信息。 通过v$sesstat可以对当前连接运行的session信息进行获取和分析;通过v$sysstat则可以对数据库启动以来的运行状况获得整体印象。 3.和等待事件相关的主要视图v$session_event->v$system_eventv$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中开始增强。 最后列举一下我对这个问题的答案:
这是我的答案,除了数据库等待、统计信息等,我还关心进程信息(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的历史等待信息等数据,是不可得的,所以很多时候我们很难回答这样的问题:
你也可能一次又一次地听到OracleSupport这样问:问题出现时系统是怎样的状况?问题出现时系统有哪些等待?你能否重现(reproduce)问题以便我们判断? 很多这样的问题是极其使人恼火的,我们当然不希望问题重现(reproduce)再次引起当机或业务损失,而那些问题看起来分明是不作为的责任推卸。可是事实是,失去了现场和当时的状态以及session的实时信息,也的确很难判断问题的所在。 从Oracle 10g开始,Oracle开始改变这一切。所以说了这么多,我只想更郑重地告诉大家:这一改变是多么得重要。 v$session视图的增强在Oracle 10g中,Oracle将v$session视图进行了全面增强,现在这个视图被赋予了更多的含义。 首先关于阻塞的信息被加入进来:
BLOCKING_SESSION记录了造成当前等待session的进程ID,来看一下以下测试,首先在session 1中执行一个更新操作,暂时不提交: 然后另外再开一个session,同样执行更新,此时的更新将处于等待:
现在来看看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迈出的一小步。 本文摘自《循序渐进-数据库管理优化与备份恢复》 加入"云和恩墨大讲堂"微信群,参与讨论学习 |
|