10g online performance tuning guide -笔记7

3.2 紧急性能方法
这个部分提供了当紧急时刻处理性能问题的方法。你已经知道了建立和改善应用性能的一系列方法的细节。然而，在紧急的情况下，系统的组件可能已经将其从一个可靠的预期的系统变成了不可靠的不满足用户需求的系统。

在这种情况下，性能工程师的职责就是快速决定到底发生了那些改变并采取相应的行动尽快回复正常的服务。大多数情况下，有必要采取立即的行动，所以缜密的性能优化工程是不现实的。

定位好了性能问题之后性能工程师必须收集充分的调试信息并且获得更清楚的性能问题或者最少要保证它不会再次发生。

调试进行状况下性能问题的方法和 先前提到的改善性能的方法 是一样的。但是在不同的阶段可以采取一些捷径因为问题的及时性特点。保持细节的注意和记录事实发现作为调试过程中的进展对于后期分析和调整任何补救措施都是有必要的。这就好比一个医生对病人做好的有耐心的记录作为将来的参考。

3.2.1 紧急性能改善方法的步骤

步骤如下：
1 回顾性能问题并收集性能问题的症状，这个过程包括如下几步
 用户关于系统性能低下的反馈，是吞吐量的问题还是响应时间的问题？
 询问在性能一切正常之后进行了那些修改，这个答案可以为问题提供线索。然而，得到客观公正的答案是很困难的。努力指出一些相关的问题点，例如为日志文件收集统计信息，那是在问题出现之前还是问题出现之后？
 使用自动调优功能区诊断和监视问题。可以参考自动性能优化方法的信息。总的来说你可以使用OEM性能工具区找出topsql 和会话。
2 理智检查应用系统中所有组件的硬盘使用状况。检查最高的CPU使用以及磁盘内存使用，还有所有系统组件的网络性能。这个快速的过程可以找出哪一层导致了这个问题。如果问题是在应用中，那么将要分析应用的调试。否则，做数据库服务器的分析。

3 决定数据库服务器是否被CPU限制或者它在等待事件上花费了时间。如果数据库服务器是CPU首先了，那么调查下列问题：
  --在操作系统级别和数据库级别消耗大量的CPU的会话。；查询v$sess_time_model来获得CPU使用量
--导致数据库级别获取buffer的会话或者sql；查询v$sesstat和v$sqlstats
--执行计划的改变导致不理想的sql执行计划；这个很难定位
--错误的设置了初始化参数
--代码的算法改变或者所有组件的升级

如果数据库会话正在等待一些事件，那么查看V$SESSION_WAIT中的等待时间去分析是什么导致了一系列的问题。V$ACTIVE_SESSION_HISTORY视图包括一个简单的会话活跃历史，这能够用来做诊断甚至是当事故结束系统恢复到了正常的状态。由于库缓存的大量争夺，不可能登陆去提交数据库的SQL，在这个情况下，使用用户历史数据去查看为什么忽然在这个latch会产生争夺如果大多数的等待事件是IO的等待时间，那么检查V$ACTIVE_SESSION_HISTORY去查看session运行了哪条sql导致了所有的输入输出。查看第十章 使用性能视图进行实例调优 在等待事件上的讨论。

4 采取紧急行动稳定系统，包括使部分以你够用下线或者控制系统上的工作负载，可能需要重启系统或者终止进程中的工作这自然牵连到了服务的级别。

5 使系统稳定性生效。对系统做了一些改变和限制，证实系统现在是稳定的，然后收集相关的统计数据的集合，然后遵循之前提到的严格的性能优化办法还原所有的功能和用户。这个过程可能需要在完成之间对应用进行有效的重建。

   

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24799772/viewspace-678104/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24799772/viewspace-678104/