rman 触发temp空间不足问题-凯发app官方网站

--检查最近5天谁用temp比较多
select *
from (select instance_number, sql_id, max(temp_sum_mb) temp_max
from (select instance_number, sample_time, sql_id, round(sum(nvl(temp_space_allocated, 0))/1024/1024) temp_sum_mb
from dba_hist_active_sess_history
where sample_time between sysdate-5 and sysdate
group by instance_number, sample_time, sql_id)
group by instance_number, sql_id
order by temp_max desc)
where rownum <= 10;

发现一个sql（这是个固定的sql_id）
0az7czjdw8z7j

看来是在检索备份信息

--检查sql执行情况
set long 1000000
set longchunksize 1000000
set lin 300 pages 1000
set trim on
set trimspool on
set echo off
set feedback off
select dbms_sqltune.report_sql_monitor(sql_id=>'&sqlid',type=>'text',report_level=>'all') mon_rpt from dual;

执行了11秒后失败，且读写超过30g！

看看历史执行情况

col username for a8
col sql_id for a13
col max_sample_time for a22
select (select username from dba_users b where b.user_id = a.user_id) username,
user_id, sql_id, session_id, session_serial# serial#, sql_exec_id, sql_exec_start, count(0),
to_char(max(sample_time), 'yyyymmdd hh24:mi:ss') max_sample_time,
(to_date(to_char(max(sample_time), 'yyyymmdd hh24:mi:ss'),
'yyyymmdd hh24:mi:ss') - sql_exec_start) * 24 * 3600 exec_seconds
from dba_hist_active_sess_history a
where sql_id = '0az7czjdw8z7j'
and to_char(sample_time, 'yyyymmdd hh24:mi') between '20221003 19:00' and '20221009 21:00'
group by user_id, sql_id, session_id, session_serial#, sql_exec_id, sql_exec_start
order by sql_exec_start;

为什么别的库没事？

是bug吗？

先不要这样想

看看备份信息实际情况
很久的都没清理

基于目前策略不应该
同样的备份软件系统，同样的配置，别的库都没事（极有可能是bug）

搭建测试环境，恢复一份全库来分析
问题复现
搜索一顿mos

再执行report 就不再报错了

原因应该是：
备份信息太多（可能是bug）导致内部检索备份信息时生成了错误的执行计划，消耗过多的temp，收集部分固定表和全部固定表（没错），再过期一下sql area，让优化器产生正确的执行计划。

在带库的备份脚本中增加

先这样。

阅读(545) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们