I start a query at SCN 500, and move to the remote site – if your SCN is 510 I return to the local site, jump the SCN and restart my query. If your SCN is 490 you jump your SCN and I continue.

“Superficial” because of the complexities of high concurrency, queries originating at both ends simultaneously, three-node queries and network latency issues. The strategy of synchronising at the end seems to be a sensible compromise between closest match and least contentious.

Say the local instance receives a message from the remote one:
“my current SCN is 123″
actually the meaning is
“my current SCN was 123, n milliseconds ago”
where “n milliseconds” is the network latency, which is unknown [but even if it were known, it wouldn't add information - since the remote SCN when the message is received can be anything between 123 and 123+(some thousands)].

Moving the lower SCN to the value of the higher SCN is just (thinking out loud as well) just a clever trick to avoid maintaining a remote-local SCN map; it can’t cure the fundamental (physical) problem outlined above.

Without freezing SCNs (stopping time on the two physical reference frames) – I can’t imagine a way to synchronize perfectly the SCNs on the two instances. So, perfect distributed read consistency cannot be achieved (again, without freezing, which is something very unscalable and prone to disaster if the network goes down just after freezing).

When I asked why he replied ‘To be sure, to be sure’.

Alternatively, is this an example of ‘two-phase commit’ ?

Thanks for blogging. Always something new and interesting.

“Fixed in Product Version: No Data”

seems to be very interesting for this argument the following metalink note/bug:

https://metalink.oracle.com/metalink/plsql/ml2_documents.showFrameDocument?p_database_id=BUG&p_id=2661680

Alberto, I agree with the general premise – but you don’t have to freeze SCNs, you only have to move the lower SCN to at least the value of the higher SCN – which could be done in one round trip from the caller. This is (presumably) why the commit/rollback trick works.

Incidentally, there is an interesting underlying issue anyway. A distributed join that operates as a nested loop need not give a read-consistent result, as the repeated execution of the query that gets second rowsource may operate at a different SCN every time – unless you start with “set transaction readonly” or do something with the isolation level. So perhaps the ‘solution’ to the problem is to remind people that they need that first step anyway, as that step probably performs the required synchronisation anyway.
(That’s also “thinking out loud” – to be tested, not trusted).

But I think that this is unavoidable, since you can’t have perfect read consistency between two different databases, since they don’t share a common “time reference frame” – by the time the statement reaches the remote database, the remote time/SCN has changed (speed of light being finite …).

It is simply not possible to map the SCNs on the two databases, unless they both freeze their scn, exchange their currect values, and then unfreeze the SCNs – which is simply not scalable; this test case is the perfect counterexample that this does not happen.

So after the Schrodinger effect, we have an Einstein effect as well :)