Oracle10g新特性——工作量自动收集
2008-08-30 12:44:31 来源:WEB开发网ASH还记录了并行查询服务的会话信息,这些信息对于诊断并行查询的等待事件很有用。如果记录的是并行查询的从进程的信息,协同服务会话的SID会被表示在QC_SESSION_ID字段中。字段SQL_ID记录了产生等待事件的SQL语句的ID,通过将它与视图V$SQL联合查询,可以找出这个令人讨厌的SQL语句。CLIENT_ID可以使在如web应用这样的共享用户环境中更容易定位是哪个客户端,这个字段可以通过存储过程DBMS_SESSION.SET_IDENTIFIER来设置。
既然ASH的信息如此有价值,那么不是把它的数据像AWR一样永久的存储起来不是更好吗?MMON进程会将这些信息存储到磁盘以服务于AWR表,并且可以通过视图DBA_HIST_ACTIVE_SESS_HISTORY来查询。
手工收集
在默认情况下,这些快照信息是自动收集的。但是你也可以随时手工收集。所有的AWR的功能都可以通过包DBMS_WORKLOAD_REPOSITORY来实现。要产生一个快照,只要执行:exec dbms_workload_repository.create_snapshot就可以了。
这样会立即产生一个快照记录在表WRM$_SNAPSHOT中,并且在典型(TYPICAL)级别上收集度量数据。如果需要收集更细的统计数据,可以在上述存储过程执行时设定参数FLUSH_LEVEL为ALL。统计数据的删除也是自动的,但也可以通过执行存储过程drop_snapshot_range()来手工删除。
基准线
一个典型的性能调优过程时从收集一个度量数据集的基准线开始,然后调整,再收集另一个基准线集。通过比较这两个基准数据集来观察调整产生的效果。在AWR中,可以通过已经存在的多个快照做处理来进行类似的推理。假设一个名叫apply_interest的显著产生性能压力的进程在下午1:00到3:00之间运行,相应的快照ID是从56到59,我们可以用以下存储过程为这些快照定一个名叫apply_interest_1的基准线:
exec dbms_workload_repository.create_baseline(56,59,’apply_interest_1’);
这一操作标识了从56到59的快照作为名为“apply_interest_1”的基准线的一部分。
用以下语句检查已经存在的基准线:
SQL> select * from dba_hist_baseline;
DBID BASELINE_ID BASELINE_NAME START_SNAP_ID END_SNAP_ID
---------- ----------- -------------------- ------------- -----------
4133493568 1 apply_interest_1 56 59
经过一些调优步骤,我们再创建另外一个基准线,名叫“apply_interest_2”,并比较与仅与两个基准线相关的快照的度量数据。像这样将一些快照独立成这样一些基准线能帮助了解性能调优产生的效果。分析完毕后,可以通过调用存储过程drop_baselin()来删除这些基准线,而快照还是会被保留。同样的,当清除规则需要清除掉旧的快照信息时,与这些旧快照信息相关的基准线不会被清除,以便于以后的进一步深入分析。
- ››特性信息
赞助商链接