Re: ORA_ROWSCN and ROWDEPENDENCIES

On Wed, 17 Jan 2007 06:48:29 -0800, DA Morgan <damorgan_at_psoug.org> wrote:

>Yesterday, I can't find it now,

 news:4mpqq2lmi9gsn09bnqk29eqlm62lusrrd2_at_4ax.com

http://groups.google.com/groups?selm=4mpqq2lmi9gsn09bnqk29eqlm62lusrrd2@4ax.com

 ...on .misc, unfortunately you've started a new thread now.

>someone wrote that ROWDEPENDENCIES has a granularity of 3 seconds.
>
>While that may have been true in the past ... it seems it another bit
>of advice that has outlived its usefulness.
>
>In 10gR2 the following produces a unique SCN for each row.
>

[snip]
>
>SELECT ora_rowscn, testcol
>FROM t
>ORDER BY 2;
 The original statement I made was:

"Whilst ROWDEPENDENCIES gets you an SCN per row, 3 seconds seems to be the closest you can get for the time of that SCN"

 The demo on René's site demonstrates it, so I won't repeat it here - see the link in the original article.

 René's page _does_ contain a statement that is potentially ambiguous, by saying "ora_rowscn has a granularity of three seconds.". However, nobody is claiming that "the SCN that you get from ora_rowsn may be an SCN from a time within 3 seconds of the SCN at the actual time of the modification" which appears to be the impression you're under.

 Instead, it's the method to convert an SCN to seconds (SCN_TO_TIMESTAMP) that has a granularity of 3 seconds (unless there are other less well documented methods to do such a conversion).

 This same granularity also shows up when you do flashback operations by timestamp instead by by SCN.

-- 
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool