OacleDatabase性能分析之LTOM.docVIP

LTOM本身提供了图形工具来展示收集到的数据，极大的减少了人为检查输出的文件的工作量。LTOM是一个java程序，可以作为实时的诊断平台部署到客户站点。 LTOM不同于其他support tools，因为它是主动的而不是被动的。LTOM提供了自动并且实时的问题检测和数据收集的功能。LTOM运行在UNIX服务器上，与操作系统紧密结合提供了对于性能问题的实时检测并收集trace文件的集成的解决方案。这样的实时处理的功能在很大程度上减少了处理问题的时间和降低了用户停机时间。传统来讲，获得必要的诊断信息处理数据库系统的性能事件的最大的问题就是在现象发生的时候去收集必要的诊断信息。另外，必要的诊断信息一般很少能被收集到，因为在问题发生时去定位问题、决定收集哪些诊断信息、如何去收集这些诊断信息会话费一些时间。更多的情况却是，问题已经过去了或者不得不关闭数据库来解决这些问题。这就迫使用户不得不等待问题再次发生时去快速收集信息。LTOM可以在数据库系统性能出现问题的时候，实时的自动检测问题并收集相应的诊断信息。 Automatic?Hang?DetectionSystem?ProfilerAutomatic?Session?Tracing 对RAC的支持 LTOM可以配置为在RAC环境下运行。具体细节查看文件$TOM_HOME/init/hangDetect.properties。要使用automatic hang detection功能，LTOM只需要安装在RAC集群的其中一个节点即可。要使用LTOM的其他功能，比如System Profiler或者Session Recorder，LTOM就需安装在RAC集群的所有节点。对于共享存储环境，LTOM针对每个节点需要安装在不同的路径下。Oracle建议也安装OSWatcher在所有节点。 这个功能必须在很了解LTOM的情况下才可以使用。在压力比较大的生成系统上自动收集大量的trace会对系统造成很大的性能压力。使用前必须明白产生这个级别的trace的后果，务必谨慎使用。Automatic Hang Detection使用了基于规则的挂起检测算法。LTOM默认的内置的一系列规则在很多情况下都已经足够了，但是修改并添加新的规则也很有必要。这些规则是基于数据库的等待事件。LTOM的挂起检测算法只考虑非空闲等待事件。为了保证能更细粒度的使用，有一系列的规则可以配置以匹配特殊的挂起事件。比如，很快发生的latch free waits造成了数据库短暂的挂起（几分钟），并且默认的针对latch free默认触发器的值设置得太高。我们可以定义一个规则，设置latch free的触发器为15秒。这样的话，任何一个等待latch free超过15s的会话就会触发diagnostic hang traces的收集。当运行LTOM，并且这个模式已经打开的情况下，自动挂起检测就会在后台运行并定期检测挂起事件。一旦任何一个会话被认定为已经挂起，诊断的trace就会自动产生。这种挂起诊断和诊断trace收集的数量都定义在规则文件$TOM_HOME/init/hangDetect.properties中。 HangAnalyze?Level?3Systemstate?Level?266Wait?60?secondsHangAnalyze?Level?3Systemstate?Level?266 如果想要修改默认收集策略的话，可以编辑文件$TOM_HOME/init/hangDetect.properties。使用自动挂起检测的好处是，如果数据库在早上2：00挂起，没有工程师在现场，必要的诊断信息会被自动收集并会产生相应的挂起报告。并且可以配置邮件通知。设置邮件通知可以编辑文件$TOM_HOME/src/ltommail.sh或者在安装重新时使用auto installer去配置。为了防止经常性的出现一旦hang出现，就会收集trace的问题，只有一组诊断trace会被收集并且不再检测挂起事件，直到这种模式被关闭然后重新启用。LTOM也会根据对数据库性能可能造成的影响自动选择额外的诊断trace收集的级别。 完全依赖于 statspack的一个问题就是不能从全局的角度来观察性能问题。非Oracle进程的信息，操作系统的内存、CPU和IO的健康状况都是没有收集到的。此外，所有静态数据的收集工具都是有问题的，因为使用单独的快照或者每15/30分钟间隔性的产生快照往往会错过那些在快照间隔内短暂出现的问题，同时也会在快照间隔的这一段时间内被平均下来。System Profiler可以持续性的收集操作系统和Ora