作为一个数据库管理员,您可能已经投资购买了第三方工具或使用自己开发的工具来在数据库运行期间采集详细的统计数据,并从这些统计数据中导出获得性能量度。在紧急的情况下,您可以访问这些量度来与当前的情况作比较。再度查看这些过去的事件可以给当前的问题带来一些启发,因此不断采集相关的统计数据对于性能分析变得很重要。
一段时间以来,Oracle 在这个领域中的解决方案是它内置的工具 Statspack。虽然某些情况下证明它是非常有价值的,但常常缺少性能故障诊断实践所需的强健性。Oracle Database 10g 提供了一个显著改进的工具:自动工作负载信息库 (AWR)。AWR 和数据库一起安装,不但采集统计数据,还采集导出的量度。
快速测试驱动程序
通过运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本,AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本从外观和感觉上类似于 Statspack,它显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出:文本格式(类似于 Statspack 报表的文本格式但来自于 AWR 信息库)和默认的 HTML 格式(拥有到部分和子部分的所有超链接),从而提供了非常用户友好的报表。现在运行该脚本以查看报表,从而对 AWR 的功能有一个了解。
实施
现在,让我们来看看 AWR 是如何设计和构建的。AWR 实质上是一个 Oracle 的内置工具,它采集与性能相关的统计数据,并从那些统计数据中导出性能量度,以跟踪潜在的问题。与 Statspack 不同,快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间,采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。要查看当前的设置,您可以使用下面的语句:
这些 SQL 语句显示快照每小时采集一次,采集的数据保留 7 天。要修改设置 — 例如,快照时间间隔为 20 分钟,保留时间为两天 — 您可以发出以下命令。参数以分钟为单位。
AWR 使用几个表来存储采集的统计数据,所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下,并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息(如检查的数据库和采集的快照),后一种类型保存实际采集的统计数据。(您可能已经猜到,H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”。)在这些表上构建了几种带前缀 DBA_HIST_ 的视图,这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关;例如,视图 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。
AWR 历史表采集的信息比 Statspack 多许多,这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以通过以下命令从数据字典中看到:
select view_name from user_views where
view_name like 'DBA\_HIST\_%' escape '\';
视图 DBA_HIST_METRIC_NAME 定义 AWR 采集到的重要的量度、它们所属的组和采集它们的单位。例如,下面是一个记录(竖直格式):
DBID : 4133493568
GROUP_ID : 2
GROUP_NAME : System Metrics Long Duration
METRIC_ID : 2075
METRIC_NAME : CPU Usage Per Sec
METRIC_UNIT : CentiSeconds Per Second
它显示一个量度“每秒 CPU 使用率”以“每秒的厘秒数”为单位进行测量,并且该量度属于一个量度组 “System Metrics Long Duration”。这条记录可以和其它的表(如 DBA_HIST_SYSMETRIC_SUMMARY)结合,以获得数据库的活动信息,形式如下:
select begin_time, intsize, num_interval,
minval, maxval, average, standard_deviation sd
from dba_hist_sysmetric_summary where metric_id = 2075;
BEGIN INTSIZE NUM_INTERVAL MINVAL MAXVAL AVERAGE SD
----- ---------- ------------ ------- ------- -------- ----------
11:39 179916 30 0 33 3 9.81553548
11:09 180023 30 21 35 28 5.91543912
... and so on ...
下面我们看看 CPU 时间是如何消耗的(以厘秒为单位)。标准差加入到了我们的分析中,它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中,平均值是每秒消耗 CPU 时间 3 厘秒,但标准差是 9.81,这意味着平均值 3 不能反映工作负载。在第二个例子中,平均值为 28,标准差为 5.9,这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。
一段时间以来,Oracle 在这个领域中的解决方案是它内置的工具 Statspack。虽然某些情况下证明它是非常有价值的,但常常缺少性能故障诊断实践所需的强健性。Oracle Database 10g 提供了一个显著改进的工具:自动工作负载信息库 (AWR)。AWR 和数据库一起安装,不但采集统计数据,还采集导出的量度。
快速测试驱动程序
通过运行 $ORACLE_HOME/rdbms/admin 目录中的 awrrpt.sql 脚本,AWR 的功能可以立即通过它从采集的统计数据和量度中生成的报表得到最好的说明。这个脚本从外观和感觉上类似于 Statspack,它显示所有的现有 AWR 快照并请求两个特定的快照作为时间间隔边界。它产生两种类型的输出:文本格式(类似于 Statspack 报表的文本格式但来自于 AWR 信息库)和默认的 HTML 格式(拥有到部分和子部分的所有超链接),从而提供了非常用户友好的报表。现在运行该脚本以查看报表,从而对 AWR 的功能有一个了解。
实施
现在,让我们来看看 AWR 是如何设计和构建的。AWR 实质上是一个 Oracle 的内置工具,它采集与性能相关的统计数据,并从那些统计数据中导出性能量度,以跟踪潜在的问题。与 Statspack 不同,快照由一个称为 MMON 的新的后台进程及其从进程自动地每小时采集一次。为了节省空间,采集的数据在 7 天后自动清除。快照频率和保留时间都可以由用户修改。要查看当前的设置,您可以使用下面的语句:
|
这些 SQL 语句显示快照每小时采集一次,采集的数据保留 7 天。要修改设置 — 例如,快照时间间隔为 20 分钟,保留时间为两天 — 您可以发出以下命令。参数以分钟为单位。
|
AWR 使用几个表来存储采集的统计数据,所有的表都存储在新的名称为 SYSAUX 的特定表空间中的 SYS 模式下,并且以 WRM$_* 和 WRH$_* 的格式命名。前一种类型存储元数据信息(如检查的数据库和采集的快照),后一种类型保存实际采集的统计数据。(您可能已经猜到,H 代表“历史数据 (historical)”而 M 代表“元数据 (metadata)”。)在这些表上构建了几种带前缀 DBA_HIST_ 的视图,这些视图可以用来编写您自己的性能诊断工具。视图的名称直接与表相关;例如,视图 DBA_HIST_SYSMETRIC_SUMMARY 是在WRH$_SYSMETRIC_SUMMARY 表上构建的。
AWR 历史表采集的信息比 Statspack 多许多,这些信息包括表空间使用率、文件系统使用率、甚至操作系统统计数据。这些表的完整的列表可以通过以下命令从数据字典中看到:
select view_name from user_views where
view_name like 'DBA\_HIST\_%' escape '\';
视图 DBA_HIST_METRIC_NAME 定义 AWR 采集到的重要的量度、它们所属的组和采集它们的单位。例如,下面是一个记录(竖直格式):
DBID : 4133493568
GROUP_ID : 2
GROUP_NAME : System Metrics Long Duration
METRIC_ID : 2075
METRIC_NAME : CPU Usage Per Sec
METRIC_UNIT : CentiSeconds Per Second
它显示一个量度“每秒 CPU 使用率”以“每秒的厘秒数”为单位进行测量,并且该量度属于一个量度组 “System Metrics Long Duration”。这条记录可以和其它的表(如 DBA_HIST_SYSMETRIC_SUMMARY)结合,以获得数据库的活动信息,形式如下:
select begin_time, intsize, num_interval,
minval, maxval, average, standard_deviation sd
from dba_hist_sysmetric_summary where metric_id = 2075;
BEGIN INTSIZE NUM_INTERVAL MINVAL MAXVAL AVERAGE SD
----- ---------- ------------ ------- ------- -------- ----------
11:39 179916 30 0 33 3 9.81553548
11:09 180023 30 21 35 28 5.91543912
... and so on ...
下面我们看看 CPU 时间是如何消耗的(以厘秒为单位)。标准差加入到了我们的分析中,它有助于确定平均数字是否反映了实际的工作负载。在第一条记录中,平均值是每秒消耗 CPU 时间 3 厘秒,但标准差是 9.81,这意味着平均值 3 不能反映工作负载。在第二个例子中,平均值为 28,标准差为 5.9,这更具有代表性。这种类型的信息趋势有助于了解几个环境参数对性能量度的影响。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/90618/viewspace-609701/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/90618/viewspace-609701/