gyj@OCM> create table gyj (id int,name varchar2(10));
Table created.
gyj@OCM> insert into gyj values(1,'GGGGGG');
1 row created.
gyj@OCM> commit;
Commit complete.
gyj@OCM> select * from gyj;
ID NAME 1 GGGGGG gyj@OCM> var x refcursor
gyj@OCM> exec open :x for select * from gyj;
PL/SQL procedure successfully completed.
gyj@OCM> update gyj set name='YYYYYY' where id=1;
1 row updated.
gyj@OCM> update gyj set name='JJJJJJ' where id=1;
gyj@OCM> print :x
ID NAME 1 GGGGGG 能真正看懂为什么print所显示的这个结果是GGGGGG，而并不是JJJJJJ，那就说明你对一致性读已了解过了。
再往下分析深入分析：做一系列的dump:
gyj@OCM> select id,name,dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from gyj;
ID NAME DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) 1 JJJJJJ 6 151
sys@OCM> alter system dump datafile 6 block 151;
System altered.
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0004.010.00000211 0x00c02d8a.0090.20 --U- 1 fsc 0x0000.00100118
0x02 0x0003.00d.000002db 0x00c02d16.00bc.06 C--- 0 scn 0x0000.00100109
bdba: 0x01800097
data_block_dump,data header at 0xd85664
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x00d85664
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f8b
avsp=0x1f77
tosp=0x1f77
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x1f8b
block_row_dump:
tab 0, row 0, @0x1f8b
tl: 13 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 6] 4a 4a 4a 4a 4a 4a
gyj@OCM> select UTL_RAW.CAST_TO_VARCHAR2(replace('4a 4a 4a 4a 4a 4a',' ')) from dual;
UTL_RAW.CAST_TO_VARCHAR2(REPLACE('4A4A4A4A4A4A',''))
JJJJJJ
sys@OCM>alter system dump datafile 3 block 11658;
*-----------------------------
- Rec #0x20 slt: 0x10 objn: 74580(0x00012354) objd: 74580 tblspc: 7(0x00000007)
- Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000Ext idx: 0
flg2: 0
uba: 0x00c02d8a.0090.1d ctl max scn: 0x0000.000ffd42 prv tx scn: 0x0000.000ffd5a
txn start scn: scn: 0x0000.00100109 logon user: 91
prev brb: 12594569 prev bcl: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L itl: xid: 0x0007.003.0000021e uba: 0x00c02c50.00a7.3a
flg: C--- lkc: 0 scn: 0x0000.001000f5
Array Update of 1 rows:
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 191
ncol: 2 nnew: 1 size: 0
KDO Op code: 21 row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x01800097 hdba: 0x01800092
itli: 1 ispac: 0 maxfr: 4858
vect = 3
col 1: [ 6] 59 59 59 59 59 59
gyj@OCM> select UTL_RAW.CAST_TO_VARCHAR2(replace('59 59 59 59 59 59',' ')) from dual;
UTL_RAW.CAST_TO_VARCHAR2(REPLACE('595959595959',''))
YYYYYY
gyj@OCM>alter system dump datafile 3 block 11542;
- Rec #0x6 slt: 0x0d objn: 74580(0x00012354) objd: 74580 tblspc: 7(0x00000007)
uba: 0x00c02d16.00bc.04 ctl max scn: 0x0000.000fff10 prv tx scn: 0x0000.000fff16
txn start scn: scn: 0x0000.001000f5 logon user: 91
prev brb: 12594451 prev bcl: 0
op: 0x03 ver: 0x01
op: Z
itli: 2 ispac: 0 maxfr: 4858
col 1: [ 6] 47 47 47 47 47 47
gyj@OCM> select UTL_RAW.CAST_TO_VARCHAR2(replace('47 47 47 47 47 47',' ')) from dual;
UTL_RAW.CAST_TO_VARCHAR2(REPLACE('474747474747',''))
GGGGGG
一到性读的例子（看上图）
事务T1提交时的SCN是30.
事务T2提交时的SCN是31.
事务T3执行了SELECT操作查询，SELECT时SNAP_SCN小于或等于30的数据，在查询到这个数据之前已
被修改过了。
假设，在这个例子中，在数据缓存中数据块B1最佳的版本是当前的版本B1.事务T3对它之后所有的变
化是不可见的，需要回滚的。对于这个问题需要两个更新执行回滚，因为当T3开始T2还没有提交。
1、描述一致性读的概念？
2、解释ORA-01555快照过旧的原因，利用实验模拟重现ORA-01555错误？
（1）原因：
a. UNDO段太小，不足以在系统上执行工作
b.你的程序跨 commit获取
c.块清除
（2）实验步骤：
create undo tablespace undotbs2 datafile '/u01/app/oracle/oradata/ocp/undotbs2.dbf' size 10M;
alter system set undo_tablespace=undotbs2;
alter system set undo_retention=2 scope=both;
第1步、session1: 目标是让b表报快照过旧的报错
conn gyj/gyj
create table a (id int,cc varchar2(10));
insert into a values(1,'hello');
commit;
create table b(id int,cc varchar2(10));
insert into b values(10,'AAAAAA');
commit; select * from a;
select * from b;
var x refcursor;
exec open :x for select * from b;
第2步、session2:修改b表,字段cc前镜像"OK"保存在UDNO段中
update b set cc='BBBBBB' where id= 10;
commit;
第3步、session 3:该条语句就是刷新缓存
conn / as sysdba
SQL> alter session set events = 'immediate trace name flush_cache'; --9i提供强制刷缓存
(alter system flush buffer_cache;--10g提供的一种刷缓存方法) 第4步、 session2: 在A表上行大的事务,多运行几次以确保，回滚段被覆盖
begin
for i in 1..20000 loop
update a set cc='HELLOWWWW';
commit; end loop;
end;
/
第5步、session 1:在B表上执行查询(第一步的查询)
SQL> print :x
ERROR:
ORA-01555: snapshot too old: rollback segment number 21 with name "_SYSSMU21$" too small
（3）解决方法
a.加大undo表空间。
b.适当设置参数undo_retention.
c.减少SQL运行时间(修改SQL ,缩减where条件后面的查询范围)
d.收集相关对象统计信息（与块清除有关）
3、说说与一致性读相关的一些重要数据字典视图？
V$TRANSACTION
V$LOCK_OBJECT
X$BH
UNDO$
TS$
dba_undo_extents
v$undostat
在整个实验中最关键的是要看懂：
数据块中的事务槽：
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0004.010.00000211 0x00c02d8a.0090.20 --U- 1 fsc 0x0000.00100118
0x02 0x0003.00d.000002db 0x00c02d16.00bc.06 C--- 0 scn 0x0000.00100109
还有回滚块中的事务槽
op: L itl: xid: 0x0007.003.0000021e uba: 0x00c02c50.00a7.3a
flg: C--- lkc: 0 scn: 0x0000.001000f5
还有对UBA地址的解析：
0x00c02d8a.0090.20 －>0000000011=3号文件,0x2d8a=11658号块，0x90=undo块被覆盖144次，０x20=第32条undo记录
0x00c02d16.00bc.06 －>0000000011=3号文件,0x2d16=11542号块，0xbc=undo块被覆盖188次，０x06=第6条undo记录
0x00c02c50.00a7.3a －>0000000011=3号文件,0x2c50=11344号块，０xa7=undo块被覆盖167次，0x3a=第58第undo记录