【问题标题】:Temp TableSpace Usage临时表空间使用
【发布时间】:2017-12-04 14:45:32
【问题描述】:

我们的系统中有一个作业正在批量处理数据,因此一些用户抱怨应用程序在作业运行时速度很慢,从 AWR 报告中我们观察到临时表空间等待即使临时表速度为 32GB 且自动扩展,是有什么方法可以检查 JOB 执行时的临时表空间使用情况。意思是我们可以检查表空间的历史使用情况。提前谢谢

【问题讨论】:

    标签: oracle oracle11g


    【解决方案1】:
    --#1: Find the maximum temporary tablespace used during a snapshot.
    select begin_time, end_time, instance_number, round(maxval/1024/1024) temp_mb
    from dba_hist_sysmetric_summary
    where metric_name = 'Temp Space Used'
    order by 1,2,3;
    
    --#2: Find SQL statements running around the same time.
    --Look for the event it was waiting on.  Was it waiting on something like
    --"resumable session", implying that no temporary tablespace was available?  Or was it
    --waiting on reading and writing temporary tablespace because of large data or a bad plan?
    select sql_id, event, round(temp_space_allocated)/1024/1024 temp_mb, sql_plan_line_id,
        dba_hist_active_sess_history.*
    from dba_hist_active_sess_history
    where sample_time between timestamp '2017-12-03 12:00:00' and timestamp '2017-12-03 13:00:00'
    order by sample_time desc;
    
    --#3: Find the slow operation in the SQL Monitor Report.  (If you're using AWR you probably 
    --have also licensed the diagnostics pack, and can use this tool.)  Find the operation that
    --used too much temporary tablespace and try to figure out why.  Are the objects simply
    --too large for the temporary tablespace?  Is there a cross join creating a huge
    --intermediate result set?  Is the execution plan bad and Oracle is sorting/hashing
    --result sets poorly?
    select dbms_sqltune.report_sql_monitor(sql_id => '[enter SQL_ID from above]') from dual;
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-05-13
      • 1970-01-01
      • 2015-11-07
      • 2020-10-26
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多