查询flashback_transaction_query 发现 OPERATION 为unknown,undo_sql 为空
有两种可能:1.UNDO被覆盖
2.未启用 supplemental log
alter database add supplemental log data;
alter database drop supplemental log data;
select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
扩展阅读:
http://space.itpub.net/11417069/viewspace-683844
Oracle补全日志(Supplemental logging)特性因其作用的不同可分为以下几种:最小(Minimal),支持所有字段(all),支持主键(primary key),支持唯一键(unique),支持外键(foreign key)。包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志。
最小(Minimal)补全日志开启后可以使得logmnr工具支持链式行,簇表和索引组织表。可以通过以下SQL检查最小补全日志是否已经开启:
SELECT supplemental_log_data_min FROM v$database; |
若结果返回YES或IMPLICIT则说明已开启最小补全日志,当使用ALL,PRIMARY,UNIQUE或FOREIGN补全日志时最小补全日志默认开启(即检查结果为IMPLICIT)。
一般情况下我们在使用逻辑备库时启用主键和惟一键的补全日志,而有时表上可能没有主键,惟一键或唯一索引;我们通过以下实验总结这种情况下Oracle的表现。
首先建立相关的测试表:
alter database add supplemental log data (primary key,unique index) columns ; create table test (t1 int , t2 int ,t3 int ,t4 int ); alter table test add constraint pk_t1 primary key (t1); –添加主键 随后使用循环插入一定量的数据 update test set t2=10; commit; — 更新数据 |
使用LOGMNR工具分析之前的操作,可以看到REDO中记录的SQL形式如下:
update “SYS”.”TEST” set “T2″ = ’10′ where “T1″ = ’64′ and “T2″ = ’65′ and ROWID = ‘AAAMiSAABAAAOhiAA/’; |
其中where字句后分别记录了主键值,被修改字段的值和原行的ROWID。
现在我们将原表上的主键去掉来观察。
alter table test drop constraint pk_t1 ; update test set t2=11; commit; — 更新数据 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2″ = ’11′ where “T1″ = ’1′ and “T2″ = ’10′ and “T3″ = ’3′ and “T4″ = ’4′ and ROWID = ‘AAAMiSAABAAAOhiAAA’; |
当没有主键的情况下,where子句后记录了所有列值和ROWID。
以下实验在存在唯一索引情况下的表现 create unique index pk_t1 on test(t1); update test set t2=15; commit; 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2″ = ’15′ where “T1″ = ’9′ and “T2″ = ’11′ and “T3″ = ’11′ and “T4″ = ’12′ and ROWID = ‘AAAMiSAABAAAOhiAAI’; 以上是t1列有唯一索引但不限定not null的情况,下面我们加上not null限制 alter table test modify t1 not null; update test set t2=21; commit; 使用LOGMNR分析可以发现,REDO中的SQL记录如下: update “SYS”.”TEST” set “T2″ = ’21′ where “T1″ = ’2′ and “T2″ = ’15′ and ROWID = ‘AAAMiSAABAAAOhiAAB’; |
如以上SQL所示,在存在唯一索引的情况下where子句后仍记录了所有列和ROWID;在存在唯一索引和非空约束的情况下表现与存在主键的情况一致。
当某个表上的列数量较多时且没有主键或唯一索引和非空约束的情况下,开启补全日志可能导致重做日志总量大幅提高。
首先建立一个存在250列的表: Drop table test; create table test ( t1 varchar2(5), t2 varchar2(5), t3 varchar2(5), t4 varchar2(5), …t250 varchar2(5)) insert into test values (‘TEST’,'TEST’ ……); commit; –将255个列填入数据 alter database drop supplemental log data (primary key,unique index) columns; –关闭补全日志 set autotrace on; update test set t2=’BZZZZ’ where t1=’TEST’; commit; 可以从自动跟踪信息中看到,本条更新产生了516的重做量。 alter database add supplemental log data (primary key,unique index) columns; –重新开启补全日志 update test set t2=’FSDSD’ where t1=’TEST’; 跟踪信息显示产生了3044的重做量。 |
补全日志因作用域的不同又可分为数据库级的和表级的。表级补全日志又可以分为有条件的和无条件的。有条件限制的表级补全日志仅在特定列被更新时才会起作用,有条件限制的表级补全日志较少使用,这里我们不做讨论。
下面我们来观察无条件限制表级补全日志的具体表现:
alter database drop supplemental log data (primary key,unique index) columns; alter table test add supplemental log data (primary key,unique index) columns; update test set t2=’ZZZZZ’; commit; 使用LOGMNR工具查看redo中的SQL:ITPUB个人空间NH2~ 来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24383181/viewspace-713637/,如需转载,请注明出处,否则将追究法律责任。
请登录后发表评论
登录
全部评论
<%=items[i].createtime%>
<%=items[i].content%> <%if(items[i].items.items.length) { %>
<%for(var j=0;j
<%}%> <%}%>
<%=items[i].items.items[j].createtime%>
<%=items[i].items.items[j].username%> 回复 <%=items[i].items.items[j].tousername%>: <%=items[i].items.items[j].content%>
还有<%=items[i].items.total-5%>条评论
) data-count=1 data-flag=true>点击查看
<%}%>
最新文章
|
转载于:http://blog.itpub.net/24383181/viewspace-713637/