自动性能统计信息(三)(Automatic Performance Statistics)

简介: 1.3 管理自动工作负载库(AWR)本节讲述如何管理AWR,包含以下主题:     ·管理快照     ·管理基线     ·管理基线模板     ·传输自动工作负载库数据     ·使用自动工作负载库视图     ·生成AWR报告     ·生成AWR对比报告     ·生成ASH报告     ·使用ASH报告1.3.1 管理快照     默认情况下,Oracle数据库每小时生成一个快照,并将统计信息保留在工作负载库中8天。
1.3 管理自动工作负载库(AWR)
本节讲述如何管理AWR,包含以下主题:
    ·管理快照
    ·管理基线
    ·管理基线模板
    ·传输自动工作负载库数据
    ·使用自动工作负载库视图
    ·生成AWR报告
    ·生成AWR对比报告
    ·生成ASH报告
    ·使用ASH报告


1.3.1 管理快照
    默认情况下,Oracle数据库每小时生成一个快照,并将统计信息保留在工作负载库中8天。必要时,你可以使用DBMS_WORKLOAD_REPOSITORY程序手动生成、删除和修改快照。要调用这些程序,用户必须拥有DBA角色。
    管理快照的基本接口是OEM。只要可能,你就应该用OEM管理快照。如果OEM不可用,你可以使用DBMS_WORKLOAD_REPOSITORY包,就像下面小节描述的:
    ·创建快照
    ·删除快照
    ·修改快照设置

1.3.1.1 创建快照
    你可以使用CREATE_SNAPSHOT程序手动创建快照以在不同于自动生成快照的时段来捕获统计信息。例如:    

点击(此处)折叠或打开

  1. BEGIN
  2.   DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
  3. END;
  4. /
    在这个例子中,为该实例创建的一个快照立刻就被生成。你可以从DBA_HIST_SNAPSHOT中查看这个快照信息。

1.3.1.2 删除快照
    你可以使用DROP_SNAPSHOT_RANGE程序来删除一个范围内的快照。可以从DBA_HIST_SNAPSHOT视图查看数据库ID和快照ID。例如,你可以删除下列范围中的快照:

点击(此处)折叠或打开

  1. BEGIN
  2.   DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 22,
  3.                            high_snap_id => 32, dbid => 3310949047);
  4. END;
  5. /
    在这个例子中,从22到32的快照全部被删除。可选项数据库ID为 3310949047,如果你不指定一个DBID值,本地数据库ID值会被作为默认值。
    当调用DROP_SNAPSHOT_RANGE程序时,属于该快照段范围所对应时段内的 ASH数据也一并被删除

1.3.1.3 修改快照设置
    你可以调整指定数据库的快照间隔、保留时间和捕获的top SQL数目,但需要注意你做的这些设置可能会影响到Oracle数据库诊断工具的诊断准确性。
    间隔就是指数据库自动生成两个快照之间的时间。保留时间即数据库将快照保留在工作负载库中的时间。topsql设置快照捕获的包含详细信息的SQL语句的数目。要修改这些设置,可以使用MODIFY_SNAPSHOT_SETTINGS程序。例如:

点击(此处)折叠或打开

  1. BEGIN
  2.   DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,
  3.                  interval => 30, topnsql => 100, dbid => 3310949047);
  4. END;
  5. /
    需要注意的是,如果不指定DBID,那么本地DBID就会作为默认值。可以从DBA_HIST_WR_CONTROL中查看当前的相关设置。

1.3.2 管理基线
    管理基线的基本的接口就是OEM。同时可以通过DBMS_WORKLOAD_REPOSITORY包来管理基线。

1.3.2.1 创建基线

点击(此处)折叠或打开

  1. BEGIN
  2.     DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 270,
  3.                    end_snap_id => 280, baseline_name => 'peak baseline',
  4.                    dbid => 3310949047, expiration => 30);
  5. END;
  6. /
    上例中,270是开始快照,280是结束快照,基线名为peak baseline。DBID选项是可选的,如果不指定,本地数据库的DBID为默认值。expiration设置为30,意即30天后基线过期将被删除。如果不指定expiration值,基线永不过期。
     系统自动给每个新创建的基线赋予一个唯一的基线ID。基线ID和DBID都可以从DBA_HIST_BASELINE中访问。

1.3.2.2 删除基线

点击(此处)折叠或打开

  1. BEGIN
  2.   DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'peak baseline',
  3.                   cascade => FALSE, dbid => 3310949047);
  4. END;
  5. /
     cascade参数设置为false,则只删除基线。如果cascade设置为true,那么用作基线设置的相关AWR快照也会删除。不指定DBID将以本地数据库DBID值作为默认值。

1.3.2.3 重命名基线
     使用DBMS_WORKLOAD_REPOSITORY包的RENAME_BASELINE程序可以重命名基线。

点击(此处)折叠或打开

  1. BEGIN
  2.     DBMS_WORKLOAD_REPOSITORY.RENAME_BASELINE (
  3.                    old_baseline_name => 'peak baseline',
  4.                    new_baseline_name => 'peak mondays',
  5.                    dbid => 3310949047);
  6. END;
  7. /
     上例基线名从 peak baseline变为 peak mondays,不指定DBID将 以本地数据库DBID值作为默认值。

     

     


    
待续












































相关文章
|
11月前
|
存储 SQL JSON
MySQL optimizer_trace cost量化分析
MySQL optimizer_trace cost量化分析
127 0
|
11月前
|
存储 Oracle 关系型数据库
Oracle优化07-分析及动态采样-DBMS_STATS 包
Oracle优化07-分析及动态采样-DBMS_STATS 包
81 0
Oracle优化07-分析及动态采样-DBMS_STATS 包
SAP QM启用了Physical Sample Management后检验批有哪些特殊地方?
SAP QM启用了Physical Sample Management后检验批有哪些特殊地方?
SAP QM启用了Physical Sample Management后检验批有哪些特殊地方?
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
SAP QM维护检验计划指派取样策略时候报错:Sampling procedure is not permitted for insp.point-related inspection
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
SAP QM中阶执行事务代码QDB1,报错- Inspection severity 001 AQL 0.650 not in sampling schema A01-
|
SQL 监控 关系型数据库
参数performance_schema设置最佳实践
最早开源MySQL从5.5开始支持performance_schema(下文简称PFS),又在后续版本不断持续完善、优化,PFS已经成为了性能诊断优化的利器,使SQL问题、锁等待事件等比较清晰地展现出来,但打开PFS也会带来相应的性能成本,本篇就来看下PFS相比其他工具及不打开PFS的性能差异。
参数performance_schema设置最佳实践