If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

For a start, I should have noted that both mentioned methods (USERENV('COMMITSCN') and MAX(ktuxescnw * POWER(2, 32) + ktuxescnb) FROM x$ktuxe) return only approximate current SCN. In fact they provide you with so called commit SCN, which is generally speaking a SCN of the most recently commited transaction, and that can be slightly different than the SCN reported by DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER().

Commit SCN usually lags behind current SCN reported by DBMS_FLASHBACK for a few numbers.

One of the problems with getting the SCN is also the fact that SCN has quite a few different meanings (current SCN, commit SCN, transaction start SCN, checkpoint SCN, .....). Maybe you can get more information about this if you search ixora site for "x$ktuxe".

The other thing is your question about "monotonically increasing" number. Well, theoretically it is, however it will sometimes appear as it is skipping some numbers. Sometimes it will increase the numbers so fast (or probably they are protected by latches/enqueues, I don't know) that you simply won't be able to see some of them and it will appear as they were skipped. For example, here is an output from my SQL/Plus session, where I was the only user connected on the system:

returns the SCN at which the last committed transaction did a commit, which is not exactly the same thing as current SCN. The reason why the above statement returned a little bit smaller number is that you should add in the ktuxescnw as well, but according to Jonathan Lewis this 'wrap' only occurs every billion or so commits, so it is probably ignored.