更正昨天发的内容
发布时间:2020-12-12 14:29:58 所属栏目:百科 来源:网络整理
导读:昨天发的文章,其实是不适用于大多数情况的,在这里特别更正一下。 我们昨天说了,如果UNDO的空间足够大,undo_retention的时间足够长,看起来没必要开归档模式呀,其实这个说法在我发完之后我就想到了一种情况,使得这个说法是不成立的。 我们来做一个实验
昨天发的文章,其实是不适用于大多数情况的,在这里特别更正一下。 我们昨天说了,如果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进去。 这样我们可以完善一下我们的说法:这种操作只适用于数据量更新不频繁的表,如果有一些表数据是实时插入的,那么这种操作就做不得,因为一闪回,数据还是会丢失的。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |