zoukankan      html  css  js  c++  java
  • [Oracle]

    ADDM 通过检查和分析AWR获取的数据来推断Oracle数据库中可能的问题。并给出优化建议。

    获取ADDM的方法例如以下:

    @?/rdbms/admin/addmrpt.sql
    以下能够看一个样例:

    --第一步:创建測试用的表
    drop table t cascade constraints purge;
    create table t AS SELECT * FROM dba_objects ;
    
    
    --第二步:快照
    exec dbms_workload_repository.create_snapshot(); 
    
    --第三步:模拟进行
    DECLARE
        v_var number;
    BEGIN
        FOR n IN 1..10000
        LOOP
            select count(*) into v_var from t;
        END LOOP;
    END;
    /
    
    
    ---第四步:再次快照
    exec dbms_workload_repository.create_snapshot(); 
    
    
    --第五步:创建一个优化诊断任务并运行
    --(1)先获取到两次快照的ID:
    select snap_id from (SELECT * FROM dba_hist_snapshot ORDER BY snap_id desc) where rownum <=2;
    
    
    --(2)创建优化任务,并运行:
    DECLARE
        task_name VARCHAR2(30) := 'ADDM_02';
        task_desc VARCHAR2(30) := 'ADDM Feature Test';
        task_id NUMBER;
    BEGIN
        dbms_advisor.create_task('ADDM', task_id, task_name, task_desc, null);
        dbms_advisor.set_task_parameter(task_name, 'START_SNAPSHOT', 2033);
        dbms_advisor.set_task_parameter(task_name, 'END_SNAPSHOT', 2034);
        dbms_advisor.set_task_parameter(task_name, 'INSTANCE', 1);
        dbms_advisor.set_task_parameter(task_name, 'DB_ID', 977587123);
        dbms_advisor.execute_task(task_name);
    END;
    /
    
    --第六步:查看优化建议结果
    --通知函数dbms_advisor.get_task_report能够得到优化建议结果。
    set pagesize 0
    set linesize 121
    spool d:addm_rpt.html
    SET LONG 1000000 PAGESIZE 0 LONGCHUNKSIZE 1000
    COLUMN get_clob FORMAT a80
    SELECT dbms_advisor.get_task_report('ADDM_02', 'TEXT', 'ALL') FROM DUAL;
    spool off


    生成的ADDM例如以下:

              任务 '任务_4125' 的 ADDM 报告
              ----------------------
    
    分析时段
    ----
    AWR 快照范围从 1908 到 1952。
    时段从 16-2月 -14 08.19.56 上午 開始
    时段在 16-2月 -14 10.00.37 下午 结束
    
    分析目标
    ----
    数据库 'TEST11G' (DB ID 为 977587123)。
    数据库版本号 11.2.0.1.0。
    ADDM 对实例 test11g 运行了分析, 该实例的编号为 1 并运行于 LIANGJB-PC。
    
    分析时段期间的活动
    ---------
    总数据库时间为 26244 秒。
    活动会话的平均数量为 .53。
    
    查找结果概要
    ------
       说明         活动的会话   建议案
                  活动的百分比
       ---------  ------  ---
    1  行锁等待数      .52 | 97.762
    2  顶级 SQL 语句  .52 | 96.742
    
    
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    
              查找结果和建议案
              --------
    
    查找结果 1: 行锁等待数
    受影响的是 .52 个活动会话, 占总活动的 97.76\%。
    -------------------------------
    发现 SQL 语句正处于行锁定等待。
    
       建议案 1: 应用程序分析
       预计的收益为 .39 个活动会话, 占总活动的 72.36\%。

    -------------------------------- 操作 在 INDEX "LJB.GENDER_IDX" (对象 ID 为 110057) 中检測到了严重的行争用。

    使用 指定的堵塞 SQL 语句在应用程序逻辑中跟踪行争用的起因。

    相关对象 ID 为 110057 的数据库对象。 原理 SQL_ID 为 "cafv93454t4jv" 的 SQL 语句在行锁上被堵塞。

    相关对象 SQL_ID 为 cafv93454t4jv 的 SQL 语句。 insert into t values ('M',78, 'young','TTT') 原理 具有 ID 130 和序列号 423 (在实例号 1 中) 的会话是构成此建议案中的优化建议 的 98% 的堵塞会话。

    建议案 2: 应用程序分析 预计的收益为 .14 个活动会话, 占总活动的 25.4\%。 ------------------------------- 操作 在 TABLE "LJB.T" (对象 ID 为 110056) 中检測到了严重的行争用。

    使用指定的阻 塞 SQL 语句在应用程序逻辑中跟踪行争用的起因。

    相关对象 ID 为 110056 的数据库对象。 原理 SQL_ID 为 "aycghy7dbzja1" 的 SQL 语句在行锁上被堵塞。 相关对象 SQL_ID 为 aycghy7dbzja1 的 SQL 语句。 delete from T WHERE GENDER='M' 原理 具有 ID 130 和序列号 423 (在实例号 1 中) 的会话是构成此建议案中的优化建议 的 100% 的堵塞会话。 导致查找结果的故障现象: ------------ 等待类 "应用程序" 消耗了大量数据库时间。 受影响的是 .52 个活动会话, 占总活动的 97.76\%。

    查找结果 2: 顶级 SQL 语句 受影响的是 .52 个活动会话, 占总活动的 96.74\%。 ------------------------------- 发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。 建议案 1: SQL 优化 预计的收益为 .38 个活动会话, 占总活动的 71.45\%。

    -------------------------------- 操作 研究 INSERT 语句 (SQL_ID 为 "cafv93454t4jv"), 确定能否够改善性能。能够利 用此 SQL_ID 的 ASH 报告来补充此处给出的信息。

    相关对象 SQL_ID 为 cafv93454t4jv 的 SQL 语句。 insert into t values ('M',78, 'young','TTT') 原理 SQL 在 CPU, I/O 和集群等待上花费的时间仅仅占其数据库时间的 0%。因此, SQL 优 化指导不适用于这样的情况。请查看 SQL 的性能数据以找出可能的改进方法。 原理 此 SQL 的数据库时间由下面部分构成: SQL 运行占 100%, 语法分析占 0%, PL/SQL 运行占 0%, Java 运行占 0%。 原理 SQL_ID 为 "cafv93454t4jv" 的 SQL 语句运行了 1 次, 每次运行平均用时 17640 秒。 原理 等待事件 "enq: TX - row lock contention" (在等待类 "Application" 中) 消耗 了数据库时间的 100% (该数据库时间为处理具有 SQL_ID "cafv93454t4jv" 的 SQL 语句时所用的时 间)。

    建议案 2: SQL 优化 预计的收益为 .13 个活动会话, 占总活动的 25.29\%。

    -------------------------------- 操作 研究 DELETE 语句 (SQL_ID 为 "aycghy7dbzja1"), 确定能否够改善性能。能够利 用此 SQL_ID 的 ASH 报告来补充此处给出的信息。 相关对象 SQL_ID 为 aycghy7dbzja1 的 SQL 语句。 delete from T WHERE GENDER='M' 原理 SQL 在 CPU, I/O 和集群等待上花费的时间仅仅占其数据库时间的 0%。因此, SQL 优 化指导不适用于这样的情况。请查看 SQL 的性能数据以找出可能的改进方法。 原理 此 SQL 的数据库时间由下面部分构成: SQL 运行占 100%, 语法分析占 0%, PL/SQL 运行占 0%, Java 运行占 0%。 原理 SQL_ID 为 "aycghy7dbzja1" 的 SQL 语句运行了 1 次, 每次运行平均用时 7917 秒 。 原理 等待事件 "enq: TX - row lock contention" (在等待类 "Application" 中) 消耗 了数据库时间的 100% (该数据库时间为处理具有 SQL_ID "aycghy7dbzja1" 的 SQL 语句时所用的时 间)。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 附加信息 ---- 各种信息 ---- 等待类 "提交" 并未消耗大量数据库时间。

    等待类 "并发" 并未消耗大量数据库时间。 等待类 "配置" 并未消耗大量数据库时间。 等待类 "网络" 并未消耗大量数据库时间。 等待类 "用户 I/O" 并未消耗大量数据库时间。

    会话连接和断开连接的调用并未消耗大量数据库时间。 对 SQL 语句的硬语法分析并未消耗大量数据库时间。 在分析时段的 99% 期间, 数据库的维护窗体是处于活动状态的。




  • 相关阅读:
    An unhandled exception occurred while processing the request.
    PIP升级或更新、PIP 升级 或 更新 失败
    SQL求两个时间差
    EF Core DBFirst 和Code First小结
    Core + Vue 后台管理基础框架9——统一日志
    .Net Core 访问 appsettings.json
    IdentityServer4 (5) 混合模式(Hybrid)
    C# async/await、WhenAll、ContinueWith 实战应用(异步做早餐)
    .NET Core Web APi FormData多文件上传,IFormFile强类型文件灵活绑定
    Unity3D天气系统插件UniStorm插件使用说明
  • 原文地址:https://www.cnblogs.com/mfrbuaa/p/5211728.html
Copyright © 2011-2022 走看看