更正昨天发的内容

2024年5月15日 105次阅读 来源: Summer的小西瓜

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

我们昨天说了，如果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。

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

    原文作者：Summer的小西瓜
    原文地址: https://segmentfault.com/a/1190000011070150
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞