- 最后登录
- 2023-8-16
- 在线时间
- 1686 小时
- 威望
- 2135
- 金钱
- 50532
- 注册时间
- 2011-10-12
- 阅读权限
- 200
- 帖子
- 5207
- 精华
- 39
- 积分
- 2135
- UID
- 2
|
3#
发表于 2012-3-20 20:04:01
ODM TEST:
SQL> oradebug setmypid;
Statement processed.
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> oradebug tracefile_name;
/s01/admin/G10R21/udump/g10r21_ora_14946.trc
declare
cursor vCUR is select 121 from mac;
v_cur number;
begin
open vCUR;
dbms_lock.sleep(60);
fetch vCUR into v_cur;
end ;
/
PARSING IN CURSOR #2 len=19 dep=1 uid=0 oct=3 lid=0 tim=1301019645435103 hv=2424324144 ad='9973f268'
SELECT 121 FROM MAC
END OF STMT
PARSE #2:c=0,e=334,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=1301019645435096
BINDS #2:
EXEC #2:c=0,e=37,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=1301019645435205
PARSE
....................................................
WAIT 60 SECONDS
FETCH #2:c=0,e=70,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=1,tim=1301019782012990
EXEC #3:c=6999,e=58609703,p=0,cr=77,cu=0,mis=0,r=1,dep=0,og=1,tim=1301019782013055
WAIT #3: nam='SQL*Net message to client' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1301019782013144
WAIT #3: nam='SQL*Net message from client' ela= 979 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1301019782014152
STAT #2 id=1 cnt=1 pid=0 pos=1 obj=56331 op='TABLE ACCESS FULL MAC (cr=3 pr=0 pw=0 time=57 us)'
WAIT #0: nam='SQL*Net message to client' ela= 5 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1301019782014262
当OPEN CURSOR 操作发生时, PL/SQL引擎转到SQL引擎负责PARSE SQL语句获得执行计划, 同时它会记录OPEN CURSOR这一刻的SNAPSHOT SCN 快照SCN, 但是Oracle并不会实际FETCH相关的数据,也不会将这些数据复制到某个地方。
直到实际FETCH 数据时才会去访问实际的数据块,这些块一般都是Current Block, The most recent version of block , 这样的块的SCN >> Snapshot scn, 需要通过UNDO数据构建 出一个SCN 合适的Best Block ,以满足Read Consistentcy;如果此时 存在的UNDO SNAPSHOT不足以构造出这样一个很久之前的Best Block的话,那么就可能出现ORA-1555错误。 |
|