今天在测试、验证DROP_SNAPSHOT_RANGE不能彻底快照的过程中遇到了DROP_SNAPSHOT_RANGE无法清理WRM$_SNAPSHOT_DETAILS表中数据的情况,测试服务器版本为10.2.0.4.0,AWR的快照是1小时采集一次数据,快照保留14天,也就是二周。具体情况如下所示:

SQL> select * from v$version;       

 

BANNER

----------------------------------------------------------------

Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

PL/SQL Release 10.2.0.4.0 - Production

CORE    10.2.0.4.0      Production

TNS for Linux: Version 10.2.0.4.0 - Production

NLSRTL Version 10.2.0.4.0 - Production

 

 

SQL> COL SNAP_INTERVAL FOR A20;

SQL> COL TETENTION FOR A26;

SQL> SELECT * FROM dba_hist_wr_control;

 

      DBID SNAP_INTERVAL        RETENTION             TOPNSQL

---------- -------------------- -------------------- ----------

3990839260 +00000 01:00:00.0    +00014 00:00:00.0     DEFAULT

 

SQL> SELECT MIN(SNAP_ID), MAX(SNAP_ID) FROM dba_hist_snapshot;

 

MIN(SNAP_ID) MAX(SNAP_ID)

------------ ------------

        7417        59195

 

SQL> 

SQL>  SELECT MIN(SNAP_ID), MAX(SNAP_ID) FROM dba_hist_snapshot;

 

MIN(SNAP_ID) MAX(SNAP_ID)

------------ ------------

        7417        59196

 

SQL> select dbid, status, count(*)

  2  from wrm$_snapshot

  3  group by dbid, status;

 

      DBID     STATUS   COUNT(*)

---------- ---------- ----------

3990839260          0       1250

 

SQL> select min(snap_id), max(snap_id), dbid from wrm$_snapshot

  2  group by dbid; 

 

MIN(SNAP_ID) MAX(SNAP_ID)       DBID

------------ ------------ ----------

        7417        59196 3990839260

 

SQL> exec dbms_workload_repository.drop_snapshot_range(7417,59196,3990839260);

 


PL/SQL procedure successfully completed.

 

SQL>  select min(snap_id), max(snap_id), dbid from wrm$_snapshot

  2  group by dbid;

 

MIN(SNAP_ID) MAX(SNAP_ID)       DBID

------------ ------------ ----------

        7417        59197 3990839260

 

SQL> select min(snap_id), max(snap_id), dbid from wrm$_snapshot

  2  group by dbid;

 

MIN(SNAP_ID) MAX(SNAP_ID)       DBID

------------ ------------ ----------

        7417        59197 3990839260

 

SQL> SELECT MIN(SNAP_ID), MAX(SNAP_ID) FROM dba_hist_snapshot;

 

MIN(SNAP_ID) MAX(SNAP_ID)

------------ ------------

        7417        59197

如上实验所示,DROP_SNAPSHOT_RANGE不能清理WRM$_SNAPSHOT_DETAILS中的数据,当然对于的空间就不会释放,另外,有些版本中Oracle仅仅修改了对应SNAPSHOT的状态,而并没有删除快照。PS:有些人可能被上面又是DBA_HIST_SNAPSHOT,又是WRM$_SNAPSHOT_DETAILS弄得有点晕,其实DBA_HIST_SNAPSHOT是视图,它的数据来源于表WRM$_SNAPSHOT_DETAILS,使用下面SQL就能查看具体定义

SELECT OWNER, VIEW_NAME, TEXT FROM DBA_VIEWS WHERE VIEW_NAME='DBA_HIST_SNAPSHOT';

"select snap_id, dbid, instance_number, startup_time,

       begin_interval_time, end_interval_time,

       flush_elapsed, snap_level, error_count

from WRM$_SNAPSHOT

where status = 0"

-------------------------------------------------------------分割线------------------------------------------------------

本来这篇文章写了好几天了,后面讨论发现其实有时候AWR快照不能删除,并不一定就是bug,也有可能是设置了AWR的基线,下面我来演示一下

SQL> select baseline_name, start_snap_id, end_snap_id

  2  from  dba_hist_baseline

  3  order by 1;

 

BASELINE_NAME            START_SNAP_ID END_SNAP_ID

------------------------ ------------- -----------

20100526                          7455        7464

20100602                          7624        7632

20100609                          7791        7800

20100616                          7959        7968

20100623                          8126        8135

20100630                          8294        8303

20100707                          8453        8477

20100714                          8621        8645

20100721                          8789        8813

20100728                          8957        8981

20100804                          9125        9149

 

BASELINE_NAME            START_SNAP_ID END_SNAP_ID

------------------------ ------------- -----------

20100811                          9293        9317

20100818                          9461        9485

20100825                          9620        9644

20100901                          9788        9812

20100908                          9957        9980

20100915                         10124       10148

20100922                         10292       10316

20100929                         10460       10484

20101006                         10628       10652

20101013                         10796       10820

20101020                         10964       10988

 

BASELINE_NAME            START_SNAP_ID END_SNAP_ID

------------------------ ------------- -----------

20101027                         11132       11156

20101103                         11300       11324

20101110                         11468       11492

20101117                         11636       11660

20101124                         11804       11828

20101201                         11972       11996

20101208                         12140       12164

20101215                         12308       12332

20101222                         12476       12500

20101229                         12644       12668

20110105                         12812       12836

 

BASELINE_NAME            START_SNAP_ID END_SNAP_ID

------------------------ ------------- -----------

20110112                         12980       13004

20110119                         13148       13172

20110126                         13316       13340

20110202                         13484       13508

SQL> SELECT MIN(SNAP_ID), MAX(SNAP_ID) FROM dba_hist_snapshot;

 

MIN(SNAP_ID) MAX(SNAP_ID)

------------ ------------

        7100        61252

 

SQL>  exec dbms_workload_repository.drop_snapshot_range(7100,7108,2179993557);

 

PL/SQL procedure successfully completed.

 

SQL> SELECT MIN(SNAP_ID), MAX(SNAP_ID) FROM dba_hist_snapshot;

 

MIN(SNAP_ID) MAX(SNAP_ID)

------------ ------------

        7287        61252

 

SQL> exec dbms_workload_repository.drop_snapshot_range(7455,7458,2179993557);

 

PL/SQL procedure successfully completed.

 

SQL>  SELECT SNAP_ID,STARTUP_TIME FROM dba_hist_snapshot

  2   WHERE SNAP_ID BETWEEN 7455 AND 7458;

 

   SNAP_ID STARTUP_TIME

---------- ---------------------------------------------------------------------------

      7455 16-JAN-10 12.18.46.000 PM

      7456 16-JAN-10 12.18.46.000 PM

      7457 16-JAN-10 12.18.46.000 PM

      7458 16-JAN-10 12.18.46.000 PM

 

SQL> 

AWR快照SNAP_ID从7455 到7458 删除不掉,其实是因为这个段的快照设置成了基线,如下截图所示,所以,如果你发现快照删除不了的话,最好先检查这个SNAP_ID段是否设置成了基线。

另外还有就是有可能一个Bug引起的,这个只出现在特定版本中,官方文档WRM$_SNAPSHOT_DETAILS Table is Not Purged (文档 ID 1489801.1) 和文档 Document 9797851.8 Bug 9797851 - WRM$_SNAPHOST_DETAILS is never purged 都有描述这个Bug

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.3 to 12.1.0.1 [Release 11.2 to 12.1]
Information in this document applies to any platform.

SYMPTOMS

The following symptoms are observed:

  • AWR purge code is not automatically purging WRM$_SNAPSHOT_DETAILS, as expected

  • Even after dropping a range of snap id's using dbms_workload_repository.drop_snapshot_range(), the table is not purged.
  • Table WRM$_SNAPSHOT_DETAILS grows indefinitely.
  • There are many orphaned entries in the table WRM$_SNAPSHOT_DETAILS.

The number of orphaned rows for the table WRM$_SNAPSHOT_DETAILS can be found by running the following sql:

SQL> SELECT MIN(snap_id),
max(snap_id) ,
cast(min(begin_time) as date) "Min Begin Time",
CAST(MAX(begin_time) AS DATE) "Max Begin Time",
COUNT(*)
FROM sys.wrm$_snapshot_details a
WHERE NOT EXISTS
(SELECT *
FROM sys.wrm$_snapshot b
WHERE b.snap_id = a.snap_id
AND a.dbid = b.dbid
and a.instance_number = b.instance_number
) MIN(SNAP_ID) MAX(SNAP_ID) Min Begin Time Max Begin Time COUNT(*)
------------ ------------ -------------------- -------------------- ----------
1 6993 29-nov-2011 21:00:01 24-sep-2012 22:00:17 577574

CAUSE

This issue is caused by an unpublished bug:

Document 9797851.8 Bug 9797851 - WRM$_SNAPHOST_DETAILS is never purged

The verification criteria for the bug are:

  1. Drop a range of snap id's using dbms_workload_repository.drop_snapshot_range()

  2. Check the corresponding snap id's in WRM$_SNAPSHOT_DETAILS.
  3. If snap id's from the range that you chose to drop are still present, then you are hitting this bug.

SOLUTION

The following solutions are available:

  • The Patch 9797851 for unpublished Bug 9797851 is available for some platforms and can be downloaded from My Oracle Support

  • If the patch is not available on your platform on a supported version, please contact Oracle Support.
  • This issue will be fixed from release Oracle 12.1

As a workaround, it is possible to manually purge the range of snap id's from the table WRM$_SNAPSHOT_DETAILS using appropriate delete statments under the guidance of Oracle Support.

Note:

在下面版本中,这些bug才fix掉了,请留意自己的版本信息。

DROP_SNAPSHOT_RANGE过程不能清理表RM$_SNAPSHOT_DETAILS的更多相关文章

  1. oracle删除表以及清理表空间

    若要彻底删除表,则使用语句:drop table <table_name> purge; 清除回收站里的信息 清除指定表:purge table <table_name>; 清 ...

  2. 数据库学习之"清理表内所有数据"

    今天在写定时任务的时候表内的数据都出现了问题,所以用了 1 truncate table 表名 来清空表内的数据

  3. Java类的初始化过程及清理

    一.类的数据成员初始化 Java中类的数据成员初试化可能有两种形式. 在定义类成员变量的地方直接提供初始化值(这是C++中不允许的) 在构造器中初试化.(Java中不存在类似C++中的初始化列表) 两 ...

  4. 【EBS】XLA_GLT表的清理

    一.Xla_glt*在出现在日记账导入中的阶段 与R11使用gl_interface表不同,R12中大部分情况下使用的是XLA_GLT_<groupId>表:子帐传送到总账的过程中,会动态 ...

  5. 生产环境zabbix3.2上亿的表数据通过表分区的方式进行历史数据清理

    生产环境zabbix3.2上亿的表数据通过表分区的方式进行历史数据清理 zabbix服务器经常报警io过载,在报警的时候发现是数据库在删除历史数据时耗时较长 数据库积攒了大量的历史数据信息,主要集中在 ...

  6. HBase Master启动过程

    master启动过程: -->首先初始化HMaster -->创建一个rpcServer,其中并启动 -->启动一个Listener线程,功能是监听client的请求,将请求放入ni ...

  7. 本地管理表空间(LMT)与自动段空间管理(ASSM)概念

    创建表空间时,extent management local 定义本地管理表空间(LMT),segment space management auto 定义自动段空间管理(ASSM). extent ...

  8. 1 - JVM随笔分类(java虚拟机的内存区域分配(一个不断记录和推翻以及再记录的一个过程))

    java虚拟机的内存区域分配   在JVM运行时,类加载器ClassLoader在加载到类的字节码后,交由jvm的执行引擎处理, 执行过程中需要空间来存储数据(类似于Cpu及主存),此时的这段空间的分 ...

  9. 金蝶K3表

    系统ID     表ID     表名     表中文名     表说明     FType     FSefDefSign0     0     t_VoucherGroup     凭证字表    ...

随机推荐

  1. js动态显示表格的汇总信息和详细信息

    我在做数据结果展示的时候,想要实现一个如下的功能:    用户可以选择一个时间段,默认显示这个时间段的汇总数据,当鼠标点击这个时间段的时候,将显示每个时间点的详细数据,再次点击的时候,详细数据收起,只 ...

  2. iOS阶段学习第20天笔记(MRC内存管理)

    iOS学习(OC语言)知识点整理 一.OC中的内存管理 1)概念:内存管理的对象为所有继承了NSObject的对象,对基本数据(如:int .float.double...)无效      OC中采用 ...

  3. jquery属性选择器

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...

  4. jquery简单原则器(匹配索引大于指定值的元素)

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...

  5. JMS中的消息通信模型

    1. MQ简介: 消息队列(Message Queue,简称MQ),是应用程序与应用程序之间的一种通信方法.应用程序通过发送和检索出入列队的针对应用程序的数据 - 消息来通信,而无需专用连接来链接它们 ...

  6. No.016:3Sum Closest

    问题: Given an array S of n integers, find three integers in S such that the sum is closest to a given ...

  7. NHibernate可视化设计插件——Mindscape.NHibernateModelDesigner

    我一直希望NHibernate能够支持像EF一样支持可视化操作,今天去网上搜了一下,发现有一个插件,类似EF的可视化功能. 下载地址:Mindscape.NHibernateModelDesigner ...

  8. 使用loadrunner进行压力测试之----post请求

    1. 发送post请求时使用web_submit_data 如: web_submit_data("create",//事务名 "Action=http://bizhi. ...

  9. css知多少(1)——我来问你来答

    1. 引言 各位前端或者伪前端(比如作者本人)的同志们,css对你们来说不是很陌生.比如我,在几年之前上大学的时候,给外面做网站就用css,而且必须用css.这样算下来也得六年多了,有些功能可能轻车熟 ...

  10. Hyhyhy – 专业的 HTML5 演示文稿工具

    Hyhyhy 是创建好看的 HTML5 演示文档的工具.它具备很多的特点:支持 Markdown,嵌套幻灯片,数学排版,兼容性,语法高亮,使用 Javascript API ,方便的骨架.它支持 Fi ...