昨天发的文章,其实是不适用于大多数情况的,在这里特别更正一下。
我们昨天说了,如果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 举报,一经查实,本站将立刻删除。