关于ORA_ROWSCN-入门底子[Oracle防范]
本文“关于ORA_ROWSCN-入门底子[Oracle防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
Oracle10g引入了一个新的ORA_ROWSCN的伪列,可以查询表中记录最后变更的SCN.这个新的伪列在某些环境下会非常有效,比方履行乐观锁定,大概增量数据抽取的时刻.但是,默许情形下,每行记录的ORA_ROWSCN是基于Block的,除非在建表的时刻履行开启行级跟踪（create table … rowdependencies）.
先来简单理解一下ORA_ROWSCN的实现原理.我们知道,每个Block在头部是记录了该block近来事件的SCN的,所以默许情形下,只需求从block头部直接获得这个值便可以了,不需求其他任何的开销,Oracle就可以做到这一点.但是这明显是不切确的,一个block中会有很多行记录,每次事件不大概影响到整个block中全部的行,所以这是一个非常不精准的预算值,同一个block的全部记录的ORA_ROWSCN城市是相同的,基本上没有多大的利用代价.
假如在建表的时刻开启行级跟踪选项,Oracle则可认为每一行记录切确的SCN,那么明显不能再直接从block头部获得.要得到充足的信息,必定要付出一定的代价,Oracle必须为每一行实际的存储这个SCN.所以这个行级跟踪的选项,只能在建表的时刻指定,而不能通过alter table来改正现有的表,不然需求改正每一行记录的物理存储格局,代价是不可思议的.
简单的做个实行便可以知道开启行级跟踪今后块记录格局的差别.建两个表,一个norowdependencies（默许）,一个rowdependencies,然后辨别dump出呼应的数据块:
| create table t1(i int); insert into t1 values(1); insert into t1 values(2); commit; create table t2 rowdependencies as select * from t1; |
norowdependencies:
| block_row_dump: tab 0, row 0, @0×1f9a tl: 6 fb: –H-FL– lb: 0×1 cc: 1 col 0: [ 2] c1 02 tab 0, row 1, @0×1f94 tl: 6 fb: –H-FL– lb: 0×1 cc: 1 col 0: [ 2] c1 03 end_of_block_dump |
rowdependencies:
| block_row_dump: tab 0, row 0, @0×1f7c tl: 12 fb: –H-FL– lb: 0×0 cc: 1 dscn 0×0000.00029ae4 col 0: [ 2] c1 02 tab 0, row 1, @0×1f6d tl: 12 fb: –H-FL– lb: 0×0 cc: 1 dscn 0×0000.00029ae4 col 0: [ 2] c1 03 end_of_block_dump |
得到行的SCN后,通过SCN_TO_TIMESTAMP函数可以转化为时间:
| SQL> select SCN_TO_TIMESTAMP(ora_rowscn) from t2 where rownum<2; SCN_TO_TIMESTAMP(ORA_ROWSCN) --------------------------------------------------------------------------- 06-JAN-09 05.31.20.000000000 PM |
乐观锁和ORA_ROWSCN
需求select … for update做悲观锁定的时刻,通过利用ORA_ROWSCN可以改成乐观锁定.一开始select数据的时刻将ORA_ROWSCN查出来,改正后假如要写回数据库之前再比对下最新的ORA_ROWSCN便可以知道这期间数据能否有发生改变.这个Tom在他的大著《Expert Oracle Database Architecture 9i and 10g Programming Techniques and Solutions 》中也是有提到的.
增量数据抽取和ORA_ROWSCN
每次抽取后记录最大的ORA_ROWSCN,下次抽取再基于上一次的SCN来得到近来改正过的数据便可.在10g之前,很多系统要实现增量数据抽取,要末通过解析日记,要末加触发器,要末就在表上加一个时间截字段.ORA_ROWSCN其实就是第三种方法,只是这个字段由Oracle来保护,这样可以避免一些利用绕过期间截去更新其他字段带来的问题.不过,假如系统中利用了逻辑备库大概streams等逻辑复制的筹划,而数据抽取又是基于逻辑备库的话,ORA_ROWSCN便大概对抽取后的数据解析有影响了,因为通过这个得到的时间是逻辑备库上记录变更的时间,而不是源库的时间了.当然,假如纯粹只是做数据抽取,而不需求利用这个时间来做解析,还是问题不大的,但还是要考虑一旦逻辑备库呈现弊端需求重做的,则这个增量抽取要怎么来处理的问题.
Metalink上搜一下ORA_ROWSCN可以看到不少相关的bug,所以在生产系统中利用的时刻要当心.比方,我在Linux64平台上的一台测试库中,履行以下语句就会碰到ORA-07445的错误:
| SQL> select ora_rowscn from x$bh where rownum<2; select ora_rowscn from x$bh where rownum<2 * ERROR at line 1: ORA-03113: end-of-file on communication channel ORA-07445: exception encountered: core dump [qkafix()+212] [SIGSEGV] [Address not mapped to object] [0x000000004] [] [] |
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“关于ORA_ROWSCN-入门底子”更多相关内容
中查找“关于ORA_ROWSCN-入门底子”更多相关内容