聊聊UNDO_RETENTION作用(下)

上篇我们讨论了小undo表空间、不支持自动拓展情况下的Undo Retention失效场景。本篇我们看一下如果存在可拓展空间,Oracle还是会尽量保证时间间隔的。

 

5、小Undo空间可拓展实验

 

我们同样创建一个小表空间,但区别在于设置其可以进行空间拓展。

 

 

SQL> select sysdate from dual;

SYSDATE

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

2013-10-16 9:27:02

 

SQL> select count(*) from t;

  COUNT(*)

----------

         0

 

SQL> select sysdate from dual;

SYSDATE

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

2013-10-16 9:27:20

 

SQL> insert into t select * from dba_objects;

75256 rows inserted

 

SQL> commit;

Commit complete

 

 

修改表空间,此时工具表MMM大小为17万。

 

 

SQL> select count(*) from mmm;

 

  COUNT(*)

----------

171029

 

 

SQL> alter database datafile '/u01/app/oradata/ORA11G/datafile/o1_mf_undotbs2_95vsgpn7_.dbf' autoextend on;

 

Database altered

 

SQL> delete mmm;

171029 rows deleted

 

SQL> commit;

Commit complete

 

 

检查空间,我们发现undo表空间大小发生了变化。从原来的20M扩大到42M

 

 

 

SQL> select file_name, AUTOEXTENSIBLE, BYTES/1024/1024 MB from dba_data_files where tablespace_name in ('UNDOTBS1','UNDOTBS2');

 

FILE_NAME                                AUTOEXTENSIBLE         MB

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

/u01/app/oradata/ORA11G/datafile/o1_mf_u YES                   105

ndotbs1_92t6zl6d_.dbf                                  

 

/u01/app/oradata/ORA11G/datafile/o1_mf_u YES                    42

ndotbs2_95vsgpn7_.dbf                                  

 

 

此时,我们是可以查找到retention范围内的数据。

 

 

SQL> select sysdate from dual;

 

SYSDATE

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

2013-10-16 9:39:38

 

SQL> select count(*) from t as of timestamp to_timestamp('2013-10-16 9:27:20','yyyy-mm-dd hh24:mi:ss');

 

  COUNT(*)

----------

         0

 

 

在这个过程中,Oracle依然会遇到覆盖失效undo空间的问题。结合undo_retention参数,系统可以做到通过拓展Undo表空间来实现对原有undo的不覆盖现象。所以,Undo表空间容量从20M增长到现在的47M,同时undo_retention所设置的时间也得到保留。

 

综合上面的实验,我们可以判断出undo_retention参数本质上是一个advisor参数。我们通过参数时间的设置,告诉Oracle说我们希望维持一个多长时间的undo保留期间。针对这个期望,Oracle会去进行调节和空间拓展动作。这个过程是一个可选择的过程,如果现实条件存在限制,即使设置了retention期间,也难以保留。

 

那么,有没有强制保留的方法呢?如果确实存在业务要求需要前镜像留存,我们从10g开始就可以使用undo retentionguarntee机制来进行保护。

 

6Undo Retention Guarntee

 

Undo Retention Guarntee是针对undo tablespace设置的一种保护机制。通常情况下,undo_retention设置的时间是一个非强依赖。通过设置undo表空间的guarntee属性,我们可以保证对应的undo空间不被覆盖回收。

 

实验数据准备。

 

 

SQL> insert into mmm select * from dba_objects;

75256 rows inserted

 

SQL> insert into mmm select * from mmm;

75256 rows inserted

 

SQL> insert into mmm select * from mmm;

150512 rows inserted

 

SQL> commit;

Commit complete

 

 

创建一个表空间,设置为guarntee

 

 

SQL> create undo tablespace undotbs3 datafile size 10M autoextend off retention guarantee;

 

Tablespace created

 

SQL> select tablespace_name, contents, retention from dba_tablespaces where contents='UNDO';

 

TABLESPACE_NAME                CONTENTS  RETENTION

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

UNDOTBS1                       UNDO      NOGUARANTEE

UNDOTBS2                       UNDO      NOGUARANTEE

UNDOTBS3                       UNDO      GUARANTEE

 

SQL> select file_name, AUTOEXTENSIBLE, BYTES/1024/1024 MB from dba_data_files where tablespace_name in ('UNDOTBS1','UNDOTBS2','UNDOTBS3');

 

FILE_NAME                                AUTOEXTENSIBLE         MB

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

/u01/app/oradata/ORA11G/datafile/o1_mf_u YES                   105

ndotbs1_92t6zl6d_.dbf                                  

 

/u01/app/oradata/ORA11G/datafile/o1_mf_u YES               44.9375

ndotbs2_95vsgpn7_.dbf                                  

 

/u01/app/oradata/ORA11G/datafile/o1_mf_u NO                     10

ndotbs3_95vw1v91_.dbf                                  

 

 

修改参数,启用undotbs3表空间。

 

 

SQL> alter system set undo_tablespace=undotbs3;

System altered

 

SQL> show parameter undo;

 

NAME                                 TYPE        VALUE

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

undo_management                      string      AUTO

undo_retention                       integer     300

undo_tablespace                      string      UNDOTBS3

 

 

下面进行空间实验。

 

 

SQL> select sysdate from dual;

 

SYSDATE

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

2013-10-16 9:51:56

 

SQL> select count(*) from mmm;

 

  COUNT(*)

----------

    301024

 

SQL> select count(*) from t;

 

  COUNT(*)

----------

     75256

 

SQL> delete t where rownum<10;

 

9 rows deleted

 

SQL> commit;

 

Commit complete

 

SQL> select count(*) from t;

 

  COUNT(*)

----------

     75247

 

 

此时我们发现,如果发现可能会覆盖在undo_retention期间数据的语句,Oracle会直接拒绝操作。

 

 

SQL> delete mmm;

delete mmm

 

ORA-30036: 无法按 8 扩展段 (在还原表空间 'UNDOTBS3' )

 

 

SQL> alter tablespace undotbs3 retention noguarantee;

Tablespace altered

 

SQL> alter tablespace undotbs3 retention guarantee;

alter tablespace undotbs3 retention guarantee

 

ORA-30036: 无法按 8 扩展段 (在还原表空间 'UNDOTBS3' )

 

 

7、结论

 

Oracle Undo机制中,undo_retention是一个非常不容易理解的参数项。简单的说,undo_retention就是用户使用Oracle过程中,对flashback和一致读的基本要求期间。设置之后,Oracle会根据自动undo管理的原则进行调节,进行空间拓展,来适应实现用户的期间要求。

 

所谓“巧妇难为无米之炊”,undo_retention是用户的期望。Oracle在进行调节过程中,会根据实际的业务频繁度和数量量、以及undo表空间设置情况进行综合评估。就是说,虽然用户设置了undo_retention的期望,在很多情况下也是不能达到的。

 

如果业务场景中真正需要进行retention period的保留,可以使用undo表空间的guarantee方法。一旦设置这个参数开关,undo_retention就成为一个强依赖参数。Oracle在这种情况下,宁可拒绝SQL DML操作,也不会允许将undo数据前镜像覆盖的情况发生。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-774565/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-774565/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值