【发布时间】:2017-12-04 14:45:32
【问题描述】:
我们的系统中有一个作业正在批量处理数据,因此一些用户抱怨应用程序在作业运行时速度很慢,从 AWR 报告中我们观察到临时表空间等待即使临时表速度为 32GB 且自动扩展,是有什么方法可以检查 JOB 执行时的临时表空间使用情况。意思是我们可以检查表空间的历史使用情况。提前谢谢
【问题讨论】:
我们的系统中有一个作业正在批量处理数据,因此一些用户抱怨应用程序在作业运行时速度很慢,从 AWR 报告中我们观察到临时表空间等待即使临时表速度为 32GB 且自动扩展,是有什么方法可以检查 JOB 执行时的临时表空间使用情况。意思是我们可以检查表空间的历史使用情况。提前谢谢
【问题讨论】:
--#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;
【讨论】: