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, @0x1f9a
tl: 6 fb: –H-FL– lb: 0×1 cc: 1
col 0: [ 2] c1 02
tab 0, row 1, @0x1f94
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, @0x1f7c
tl: 12 fb: –H-FL– lb: 0×0 cc: 1
dscn 0×0000.00029ae4
col 0: [ 2] c1 02
tab 0, row 1, @0x1f6d
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] [] []