在这介绍Oracle 10G开始提供的一个伪列ORA_ROWSCN,它又分为两种模式一种是基于block这是默认的模式(块级跟踪)；还有一种是基于row上，这种模式只能在建里表时指定ROWDEPENDENCIES(行级跟踪)，不可以通过后期的alter table语句来将表修改为ROWDEPENDENCIES。
我们知道，每个Block在头部是记录了该block最近事务的SCN的，所以默认情况下，只需要从block头部直接获取这个值就可以了，不需要其他任何的开销，Oracle就能做到这一点。但是这明显是不精确的，一个block中会有很多行记录，每次事务不可能影响到整个block中所有的行，所以这是一个非常不精准的估算值，同一个block的所有记录的ORA_ROWSCN都会是相同的，基本上没有多大的使用价值。
如果在建表的时候开启行级跟踪选项，Oracle则可以为每一行记录精确的SCN，那么显然不能再直接从block头部获取。要获得足够的信息，肯定要付出一定的代价，Oracle必须为每一行存储这个实际的SCN。所以这个行级跟踪的选项，只能在建表的时候指定，而不能通过alter table来修改现有的表，否则需要修改每一行记录的物理存储格式，代价是可想而知的。
在10g之前，很多系统要实现增量数据抽取，要么通过解析日志，要么加触发器，要么就在表上加一个时间截字段。ORA_ROWSCN其实就是第三种方式，只是这个字段由Oracle来维护，这样可以避免一些应用绕过时间截去更新其他字段带来的问题。
下面做一个实验来证明，首先在默认状态下修改同一个块上的其中一条数据，然后再启用行级跟踪，修改同一块上的一条数据，观察ora_rowscn变化。
第一种方式（块级跟踪）：
select ora_rowscn,
dbms_rowid.ROWID_BLOCK_NUMBER(rowid) blockid,
scn_to_timestamp(ora_rowscn)
from hs_futures.fuentrust t
order by scn_to_timestamp(ora_rowscn);
dbms_rowid.ROWID_BLOCK_NUMBER(rowid)：是为获取数据所在块的ID
scn_to_timestamp(ora_rowscn)：获取数据最所修改的时间
数据发现变化后通过上面SQL语句可以查看到数据最后修改的时间，注意因为是同一个块上，所以这个块上只要有DML操作那么所有数据的scn都更新了，所以凡是跟这条记录在同一个块上数据获取到的ora_rowscn和scn_to_timestamp(ora_rowscn)两个值都发生了相应的变化。
第二种方式（行级跟踪）：
create table hs_futures.fuentrust_test1 rowdependencies as
select * from hs_futures.fuentrust
用以上语句创建一个基于ROWDEPENDENCIES模式的表，然后用第一种方法中的SQL去查询此表数据中的ora_rowscn，scn_to_timestamp(ora_rowscn)两个值，修改其中的某一条记录然后再去查询那个值发现发生变化的只是被修改那条记录的这两个值发生了变化，而在同一个块中没有被修改的其它记录这两个值是不会产生变化的。
注意DDL操作：只要现有表记录中的数据有发生变化那么SCN肯定就会发生更新，如删除有数据的列，但是如果索引删除/修改/增加及增加/者删除没有任何数据的列那么SCN是不会有任何变化。