[20170420]关于延迟块清除3.txt
--昨天做延迟块清除测试时，有一个问题我自己一直没搞明白，就是把表空间设置为只读的情况下，当访问块时，
--由于没法更新对应块，不知道为什么每次重启数据库，正常undo的事务槽不可能这么块覆盖，为什么ora_rowscn
--总是变化，而且取的是control scn，要认真探究一下问题在那里。
--上午测试没有测试出来,链接http://blog.itpub.net/267265/viewspace-2137714/ => [20170420]关于延迟块清除2.txt
--中午有看了原来的链接http://blog.itpub.net/267265/viewspace-1561104/ => [20150409]只读表空间与延迟块清除.txt
--我清楚的记得我每次重启。访问ora_rowscn每次重启数据库后都是变化的，我的测试环境没有什么事务，不大可能出现这样
--的情况，唯一的可能还是IMU在作怪，我以前的测试都是打开flashback的，这样IMU是失效的，决定测试关闭IMU的情况。
1.环境：
SCOTT@book> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
SCOTT@book> alter database flashback on;
Database altered.
--//打开flashback ，就关闭了IMU。
SCOTT@book> select flashback_on from v$database ;
FLASHBACK_ON
------------------
YES
CREATE TABLESPACE TEA DATAFILE
'/mnt/ramdisk/book/tea01.dbf' SIZE 40M AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
LOGGING
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT MANUAL
FLASHBACK ON;
--//安全起见重启数据库再测试。
2.测试:
SCOTT@book> create table deptx tablespace tea as select * from dept ;
Table created.
SYS@book> @ &r/bh 6 128
HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME
---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- --------------------
0000000084971710 6 128 4 segment header xcur 1 0 0 0 0 0 0000000076CF8000 DEPTX
SYS@book> @ &r/bh 6 129
no rows selected
--//建立表，并没有读取dba=6,129.这是块新化。
SCOTT@book> update deptx set dname=lower(dname) where deptno=10;
1 row updated.
SYS@book> @ &r/bh 6 129
HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME
---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- --------------------
0000000084B29130 6 129 1 data block xcur 1 0 0 0 0 0 0000000076D70000 DEPTX
0000000084B29130 6 129 1 data block cr 1 1115588613 3 0 0 0 0000000076D72000 DEPTX
SYS@book> alter system flush buffer_cache;
System altered.
HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME
---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- --------------------
0000000084B29130 6 129 1 data block free 0 0 0 0 0 0 0000000076D70000 DEPTX
0000000084B29130 6 129 1 data block free 0 0 0 0 0 0 0000000076D72000 DEPTX
--//在IMU关闭情况下,alter system flush buffer_cache;,脏块清除，STATE=free.没有开启IMU要多次执行才有效的情况。
SCOTT@book> alter tablespace tea read only ;
Tablespace altered.
3.现在测试环境已经建立好。
SCOTT@book> alter system dump datafile 6 block 129;
System altered.
SYS@book> @ &r/bh 6 129
HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME
---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- --------------------
0000000084B29130 6 129 1 data block free 0 0 0 0 0 0 0000000076D70000 DEPTX
0000000084B29130 6 129 1 data block free 0 0 0 0 0 0 0000000076D72000 DEPTX
--//这样转储方式并没有将块读入数据缓存。
Block header dump: 0x01800081
Object id on Block? Y
seg/obj: 0x16508 csc: 0x03.427e8786 itc: 3 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0003.427e8786
0x02 0x000a.013.000050dd 0x00c03ddd.0fe1.12 ---- 1 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
--//可以发现使用ITL=0x02. Xid = 0x000a.013.000050dd.
SCOTT@book> select * from v$rollname where usn=10;
USN NAME
---------- ------------------------------
10 _SYSSMU10_1197734989$
SCOTT@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$';
System altered.
TRN CTL:: seq: 0x0fe1 chd: 0x0015 ctl: 0x001d inc: 0x00000000 nfb: 0x0002
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03ddd.0fe1.17 scn: 0x0003.427e8566
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x12 9 0x00 0x50db 0x000e 0x0003.427e88a3 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 1492759839
0x13 9 0x00 0x50dd 0x0012 0x0003.427e8888 0x00c03ddd 0x0000.000.00000000 0x00000001 0x00000000 1492759822
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x14 9 0x00 0x50d4 0x001c 0x0003.427e876e 0x00c03ddc 0x0000.000.00000000 0x00000001 0x00000000 1492759567
--//0x427e8888 = 1115588744
SCOTT@book> select power(2,32)*3+1115588744 from dual ;
POWER(2,32)*3+1115588744
------------------------
14000490632
--//注意看下划线，如果现在访问数据块,ora_rowscn应该显示0x0003.427e8888.转换成数字就是14000490632.
SCOTT@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000490632 10 accounting NEW YORK 14000491307
--//ok,显示正确，猜测也正确。因为表空间只读，无法写入。
4.现在重启数据库看看。
SYS@book> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@book> startup
ORACLE instance started.
Total System Global Area 634732544 bytes
Fixed Size 2255792 bytes
Variable Size 197133392 bytes
Database Buffers 427819008 bytes
Redo Buffers 7524352 bytes
Database mounted.
Database opened.
SYS@book> alter system flush buffer_cache;
System altered.
SYS@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$';
System altered.
TRN CTL:: seq: 0x0fe1 chd: 0x000b ctl: 0x0017 inc: 0x00000000 nfb: 0x0002
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03de4.0fe1.1a scn: 0x0003.427e8d19
---------------------------------------------
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x12 9 0x00 0x50df 0x000e 0x0003.427e8db8 0x00c03de2 0x0000.000.00000000 0x00000001 0x00000000 1492760745
0x13 9 0x00 0x50e1 0x0012 0x0003.427e8db6 0x00c03de2 0x0000.000.00000000 0x00000001 0x00000000 1492760745
------------------------------------------------------------------------------------------------------------------------
0x14 9 0x00 0x50d9 0x000a 0x0003.427e8fd8 0x00c03de4 0x0000.000.00000000 0x00000001 0x00000000 1492760985
--//为了对比的方便，把前面的显示paste下来。
TRN CTL:: seq: 0x0fe1 chd: 0x0015 ctl: 0x001d inc: 0x00000000 nfb: 0x0002
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03ddd.0fe1.17 scn: 0x0003.427e8566
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x12 9 0x00 0x50db 0x000e 0x0003.427e88a3 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 1492759839
0x13 9 0x00 0x50dd 0x0012 0x0003.427e8888 0x00c03ddd 0x0000.000.00000000 0x00000001 0x00000000 1492759822
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x14 9 0x00 0x50d4 0x001c 0x0003.427e876e 0x00c03ddc 0x0000.000.00000000 0x00000001 0x00000000 1492759567
--//你可以发现我重启数据库,undo 事务槽0x13已经被覆盖。很奇怪我的测试环境事务很少，感觉正常关闭重启数据库后，oracle做了与
//打开IMU环境下不同的操作，还是在IMU关闭的情况下UNDO事务槽 很容易覆盖，11g下仅仅34个槽.
--//这样如果现在访问数据块。ora_rowscn应该显示0x0003.427e8d19.转换成数字就是14000491801。
SCOTT@book> @ &r/scn10 0x0003.427e8d19
C20 SCN_ SCN_BASE SCN_WRAP SCN_BASE SCN
-------------------- ---- -------- ------------ ------------ ------------
0x0003.427e8d19 0003 427e8d19 3 1115589913 14000491801
--//验证看看。
SCOTT@book> set numw 12
SCOTT@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000491801 10 accounting NEW YORK 14000492848
--//完成对上。
5.再次重启，设置数据库read only看看。
SYS@book> startup mount
ORACLE instance started.
Total System Global Area 634732544 bytes
Fixed Size 2255792 bytes
Variable Size 197133392 bytes
Database Buffers 427819008 bytes
Redo Buffers 7524352 bytes
Database mounted.
SYS@book> alter database open read only;
Database altered.
SYS@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$';
System altered.
TRN CTL:: seq: 0x0fe1 chd: 0x0003 ctl: 0x0008 inc: 0x00000000 nfb: 0x0001
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03dea.0fe1.25 scn: 0x0003.427e92db
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x11 9 0x00 0x5039 0x0009 0x0003.427e92e1 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x12 9 0x00 0x50e3 0x0013 0x0003.427e931d 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
0x13 9 0x00 0x50e5 0x001a 0x0003.427e931f 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
--//undo TRN CTL 有发生了变化。scn: 0x0003.427e92db
SYS@book> @ &r/scn10 0x0003.427e92db
C20 SCN_ SCN_BASE SCN_WRAP SCN_BASE SCN
-------------------- ---- -------- ------------ ------------ ------------
0x0003.427e92db 0003 427e92db 3 1115591387 14000493275
SYS@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000493367 10 accounting NEW YORK 14000493376
--//这次就对不上了。
select 14000493367,trunc(14000493367/power(2,32)) scn_wrap,mod(14000493367,power(2,32)) scn_base from dual
14000493367 SCN_WRAP SCN_BASE SCN_WRAP16 SCN_BASE16
------------ ------------ ------------ ---------- ----------
14000493367 3 1115591479 3 427e9337
--//查询转储文件，查询字符串427e9337
TRN CTL:: seq: 0x0fe1 chd: 0x0003 ctl: 0x0008 inc: 0x00000000 nfb: 0x0001
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03dea.0fe1.25 scn: 0x0003.427e92db
Version: 0x01
FREE BLOCK POOL::
uba: 0x00c03dea.0fe1.25 ext: 0x3 spc: 0xa0c
uba: 0x00000000.0fe1.02 ext: 0x3 spc: 0x1f06
uba: 0x00000000.0fe1.03 ext: 0x3 spc: 0x19c0
uba: 0x00000000.0fdc.44 ext: 0x41 spc: 0x202
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
TRN TBL::
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x50df 0x0006 0x0003.427e92e7 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x01 9 0x00 0x50e0 0x0012 0x0003.427e931b 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x02 9 0x00 0x50e4 0x0004 0x0003.427e9331 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x03 9 0x00 0x50e4 0x0007 0x0003.427e92dd 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x04 9 0x00 0x50c3 0x0008 0x0003.427e9333 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x05 9 0x00 0x50e4 0x000d 0x0003.427e92f3 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x06 9 0x00 0x50e3 0x0021 0x0003.427e92e9 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x07 9 0x00 0x50d1 0x0011 0x0003.427e92df 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x08 9 0x00 0x50e8 0xffff 0x0003.427e9337 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x09 9 0x00 0x50dc 0x0000 0x0003.427e92e5 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0a 9 0x00 0x50e0 0x001c 0x0003.427e92fd 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0b 9 0x00 0x50e6 0x0001 0x0003.427e9317 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0c 9 0x00 0x50e6 0x001b 0x0003.427e9329 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0d 9 0x00 0x50e3 0x0019 0x0003.427e92f5 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0e 9 0x00 0x50e5 0x000c 0x0003.427e9327 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x0f 9 0x00 0x50e0 0x0005 0x0003.427e92ef 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x10 9 0x00 0x50e8 0x0018 0x0003.427e9309 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x11 9 0x00 0x5039 0x0009 0x0003.427e92e1 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x12 9 0x00 0x50e3 0x0013 0x0003.427e931d 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x13 9 0x00 0x50e5 0x001a 0x0003.427e931f 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x14 9 0x00 0x50dc 0x000a 0x0003.427e92fb 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x15 9 0x00 0x50ec 0x0002 0x0003.427e932f 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x16 9 0x00 0x50e3 0x001e 0x0003.427e9305 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x17 9 0x00 0x50e6 0x000b 0x0003.427e9311 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x18 9 0x00 0x50c7 0x001f 0x0003.427e930d 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x19 9 0x00 0x50e1 0x0014 0x0003.427e92f7 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1a 9 0x00 0x50e3 0x000e 0x0003.427e9325 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1b 9 0x00 0x50dc 0x001d 0x0003.427e932b 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1c 9 0x00 0x50dc 0x0016 0x0003.427e9301 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1d 9 0x00 0x50a0 0x0015 0x0003.427e932d 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1e 9 0x00 0x50df 0x0010 0x0003.427e9307 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x1f 9 0x00 0x50c8 0x0017 0x0003.427e930f 0x00c03dea 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x20 9 0x00 0x50ce 0x000f 0x0003.427e92ed 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
0x21 9 0x00 0x4b65 0x0020 0x0003.427e92eb 0x00c03de9 0x0000.000.00000000 0x00000001 0x00000000 1492761522
--//取scn的是 index = 0x08 行。
--//共34槽。我记得以前看书core，chd: 0x0003 ctl: 0x0008, chd:表示头，ctl:表示尾。注意看uel列，从index=0x03看起。
03->07->11->09->06->21->20->0f->05->0d->19->14->0a->1c->16->1e->10->18->1f->17->0b->01->12->13->1a->0e->0c->1b->1d->15->02->04->08->ff。
--如果看里面的scn好也是依次递增。scn从 0x0003.427e92dd => ... => 0x0003.427e9337。
--//换一句话讲在read only打开的情况，在访问数据块时块清除的情况下取的scn不是取最小的scn，而是最大的scn。
--//验证的方法很简单。重新启动数据库看看就明白了。
SYS@book> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@book> startup
ORACLE instance started.
Total System Global Area 634732544 bytes
Fixed Size 2255792 bytes
Variable Size 197133392 bytes
Database Buffers 427819008 bytes
Redo Buffers 7524352 bytes
Database mounted.
Database opened.
SYS@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000493353 10 accounting NEW YORK 14000494000
--//在数据库读写的情况下显示的是 14000493353，现在显示比前面还小，14000493353-14000493367=-14.^_^能出现scn倒退的情况。
SYS@book> alter system flush buffer_cache;
System altered.
SYS@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$';
System altered.
TRN CTL:: seq: 0x0fe1 chd: 0x001b ctl: 0x000c inc: 0x00000000 nfb: 0x0001
mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00c03deb.0fe1.3a scn: 0x0003.427e9329
SYS@book> @ &r/scn10 0x0003.427e9329
C20 SCN_ SCN_BASE SCN_WRAP SCN_BASE SCN
-------------------- ---- -------- ------------ ------------ ------------
0x0003.427e9329 0003 427e9329 3 1115591465 14000493353
--//不清楚在read only的情况为什么要这样取。具体我就不清楚了。至于IMU下为什么出现这样的情况，我也不清楚，超出我的能力。
--//而且我发现在关闭IMU的情况下，undo control scn更新很快，等几分钟：
SYS@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000493715 10 accounting NEW YORK 14000494614
--//现在14000493715 有发生了变化。再等1会，有变了。而打开IMU的情况下，就没有这么快。感觉关闭IMU环境下覆盖很快。
--//还是undo参数设置太小
SYS@book> show parameter undo
NAME TYPE VALUE
--------------- -------- ---------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SYS@book> select ora_rowscn,deptx.*,dbms_flashback.get_system_change_number from scott.deptx where rownum=1;
ORA_ROWSCN DEPTNO DNAME LOC GET_SYSTEM_CHANGE_NUMBER
------------ ------------ -------------- ------------- ------------------------
14000495424 10 accounting NEW YORK 14000495565
--//那位能给出为什么会这样？？？欢迎解答............
