全部答案

2017-07-27 18:32:38

•   在处理被ADDM捕捉的突发的性能问题中，10g等待接口提供非常有价值的数据用于诊断。作为一个DBA，你可能遇到过很多次用户抱怨“数据库非常慢了”。那么你是如何定位这种问题的呢？你第一步要做的肯定是查看是否有会话在等待数据库内部或外部的什么资源。
    
  Oracle提供了一个简单但是又很有效的机制来获取这些信息：视图V$SESSION_WAIT。这一视图提供了各种信息以帮助诊断如一个会话正在等待和已经等待的事件、及等待了多少、等待时间多长。例如，如果会话正在等待事件“db file sequential read”，字段P1和P2就标识会话正在等待的数据块的file_id和block_id。
    
  对于大多数等待事件来说，这个视图已经足够了。但由于以下两个原因，它很难成为一个强有力的优化工具：
  · 这个视图只是当前状态的一个快照。当等待不存在了，会话早前关于这些等待的历史信息也没有了，使事后诊断分析变得很困难。
  V$SESSION_EVENT视图提供了累积的但不够详细的数据。
    
  · V$SESSION_WAIT视图仅包含了等待事件的信息。要获取其他相关信息如USERID和终端信息就必须和视图V$SESSION连接查询。
  在Oracle 10g中，等待接口从根本上被重新设计了，提供了更多的信息，而且减少了DBA的干预。
    在这篇文章中，我们将探索这些特性，看看它们如何帮助我们来诊断性能问题。对于大多数性能问题，你能从ADDM中得到扩展的分析信息，但是ADDM没有捕捉到哪些即时问题的信息。而等待接口提供了非常有用的数据用于诊断。
  增强的会话等待
  首先一个增强就是对视图V$ESSION_WAIT本身的。
    这可以从一个例子来解释。加入您的用户抱怨会话被hang住了。你查出这个会话的SID，并从视图V$SESSION_WAIT中找出这个SID的记录。

  全部
  

  t***

  2017-07-27 18:32:38

  43 2 评论

  分享
  提交评论