Recently online system appear in a table of data duplication, however unlikely this case based on the business process is concerned, but unfortunately did not join the timestamp in the table, so the question becomes bad check.
So the online search-related data and found that you can query with the following statement:
select t.seq_id,t.hall_id,to_char(scn_to_timestamp(ORA_ROWSCN),'yyyy-mm-dd hh24:mi:ss:ff8') insert_time from dim_geog_a t;
The query structure as shown below:
But this statement to query the table is even related records can not be more than five days otherwise they will be reported to the system change is not a valid error number.
described as follows:
Cause
This is expected behavior as the SCN must be no older than 5 days as part of the current flashback database
features.
Currently, the flashback query feature keeps track of times up to a
maximum of 5 days. This period reflects server uptime, not wall-clock
time. You must record the SCN yourself at the time of interest, such as
before doing a DELETE.
We can query each record rowscn by the following statement.
SELECT --deptno,
--dname,loc,
dbms_rowid.rowid_block_number(ROWID) blockno,
ora_rowscn
FROM dim_geog_a;
select * from dim_geog_a as of scn 74757285358;
网上相关资料说能够建表时加参数知晓行级的scn信息，但是我查询不可行()即统一时间内插入的是一样的，只有间隔一点时间才不一样。
默认情况下，每行记录的ORA_ROWSCN是基于Block的，这样是不准确的，除非在建表的时候执行开启行级跟踪(create table … rowdependencies)，这样就会是在行级记录scn。
待得到答案后再更新。