微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

更正昨天发的内容

昨天发的文章,其实是不适用于大多数情况的,在这里特别更正一下。

我们昨天说了,如果UNDO的空间足够大,undo_retention的时间足够长,看起来没必要开归档模式呀,其实这个说法在我发完之后我就想到了一种情况,使得这个说法是不成立的。

我们来做一个实验,还是昨天那些例子,只不过稍微变动一下。

我们执行下面的这些语句:

sql> update testlijian set name ='lijian6' where name = 'lijian4';
1 row updated

sql> commit;
Commit complete

sql> 
sql> select versions_xid,name
  2  from testlijian
  3  versions between scn minvalue and maxvalue;
VERSIONS_XID     NAME
---------------- --------------------------------------------------
0700100003730000 lijian6
                 lijian4
                 wangsiqi
                 helloworld

sql> 
sql> select operation,undo_sql
  2  from flashback_transaction_query
  3  where xid = hextoraw('0700100003730000');
OPERATION                        UNDO_sql
-------------------------------- --------------------------------------------------------------------------------
UPDATE                           update "JLLT_DM"."TESTLIJIAN" set "NAME" = 'lijian4' where ROWID = 'AAAW08AAFAAK
BEGIN                            

sql> alter table testlijian enable row movement;
Table altered

sql> select * from testlijian;
NAME
--------------------------------------------------
lijian4
wangsiqi
helloworld

一个步骤没有贴出来,那就是在我update完事之后,我又insert进去一条lijian6进去。
之后我们再用flashback闪回到update操作之前,结果可以看到,lijian6消失了,lijian5变成了lijian4。

这样我们可以完善一下我们的说法:这种操作只适用于数据量更新不频繁的表,如果有一些表数据是实时插入的,那么这种操作就做不得,因为一闪回,数据还是会丢失的。

原文地址:https://www.jb51.cc/oracle/207802.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐