分类：
2008-10-28 09:41:23
在10g中，以前版本中比较难于获取的响应时间数据将会变得非常容易获取。
在以前看来，为了尽量获得数据库的最佳性能，的DBA们和性能分析专家一直很困难获得系统以及用户会话活动的一致的响应时间数据。DBA们面临的问题一直以来包括两个方面：第一个方面是准确定位数据库或者用户会话究竟在哪里消耗了时间；第二个方面就是确定用户体验的客观性质。
在数据库中产生所有可能的行为和交互作用，这些任务都不是没有价值的。Oracle等待接口，在之前的很早的Oracle数据库版本中开始介绍的，对于那些知道如何使用等待接口的管理员来说这已经成为一个伟大的开始，即使它仍然缺乏告诉DBA系统或者用户会话是否有效的处理了事务或者查询这个理想的能力。启用和钻研跟踪文件能够这个级别上的详细信息，但是对于大多数超负荷工作管理大型数据库的DBA们，这个钻研是奢侈的而耗费时间的。
幸运的是，那些将数据库升级到Oracle10g的DBA们将会发现找到主要的响应时间变得很容易，可以允许一个非常好的图表来显示系统和会话级的响应时间数据。很重要的一点，Oracle的ADDM提供了一个查看响应时间的方法，通过自动分析收集的统计信息，识别问题区域，甚至可以通过Oracle企业管理器网络控制的图形界面提供建议。
此外，与我们这里讨论相关的是Oracle10g数据库的历史数据机制允许DBA们按时查看对响应时间趋势的分析，这将有助于DBA们确定事务/系统的高峰时期，更好的定位那些拉长批处理周期和ETL作业的进程和SQL语句。
这里主要讨论用于系统、会话和SQL级别上那些历史机制的用途。
系统层的响应时间分析：
先来看看典型的几个经常问到DBA们的问题：
通常来说，数据库运行的状况如何？
用户体验感觉的平均响应时间是多少？
什么行为是最影响整个响应时间的？
上述问题在Oracle10g数据库之前对于DBA们来说是相当不好回答的，但是如果使用了最新的Oracle10g数据库之后，这些数据信息将会很容易的被捕获到。
首先，Oracle10g数据库运行的状况如何这个问题可以通过下面的查询来获得：
select METRIC_NAME，VALUE
from SYS.V_$SYSMETRIC
where METRIC_NAME IN （'Database CPU Time Ratio'，'Database Wait Time Ratio'）
AND INTSIZE_CSEC = （select max（INTSIZE_CSEC） from SYS.V_$SYSMETRIC）；
METRIC_NAME VALUE
------------------------------ ----------------------------------
Database Wait Time Ratio 31.3499111
Database CPU Time Ratio 68.6500888
Oracle10g数据库中的V$SYSMETRIC视图中存在一些非常有用的响应时间数据，其中两个比较重要的就是Wait Time Ratio 和Database CPU Time Ratio.上面的查询显示了数据库中最新的关于这两个统计数据的快照，这将有助于帮助我们确定是否数据库正在经历着一个比较高的等待百分率和瓶颈。数据库的CPU Time Ratio是由数据库中的"database time"的数值除以CPU的数量，"database time"定义为数据库消耗在用户级别调用所花费的时间（不包括实例的后台进程活动所消耗的时间）。比较高的值（90%-95%以上）代表很少等待和瓶颈活动，因为各个系统不同，这个阀值只能作为一个一般的规则来使用。
[1]
