Comments on: Distributed DML

By: Hass Khan

Hass Khan — Wed, 05 Sep 2012 05:19:11 +0000

Andras Gabor …Thank you for the wonderful comment . By bulk collecting the select into an array and then inserting forall works perfectly .

By: Distributed Queries – 2 « Oracle Scratchpad

Distributed Queries – 2 « Oracle Scratchpad — Wed, 24 Nov 2010 10:12:09 +0000

[...] consequence the driving site for a distributed query will be the local database unless you use the /*+ driving_site */ hint to change [...]

By: Distributed Pipelines « Oracle Scratchpad

Distributed Pipelines « Oracle Scratchpad — Thu, 07 Oct 2010 18:08:57 +0000

[...] an article that I wrote about the /*+ driving_site */ hint a few months ago I pointed out that the hint was not supposed to work with “create table as [...]

By: Ignoring Hints « Oracle Scratchpad

Ignoring Hints « Oracle Scratchpad — Wed, 19 May 2010 21:05:44 +0000

[...] Jonathan Lewis @ 9:04 pm UTC May 19,2010 I’ve previously published a couple of notes (here and here) about the driving_site() hint. The first note pointed out that the hint was deliberately [...]

By: Distributed Queries « Oracle Scratchpad

Distributed Queries « Oracle Scratchpad — Sun, 05 Jul 2009 06:11:31 +0000

[...] Execution plans, Hints — Jonathan Lewis @ 7:20 am UTC Jul 1,2009 Some time ago I wrote a note about distributed DML, pointing out that the driving_site() hint works with distributed queries but not with distributed [...]

By: jiri

jiri — Tue, 13 Jan 2009 23:40:09 +0000

just to add to Andras … yeah I use the same approach BULK COLLECT, I use FORALL and commit after X number of rows (one large insert can eat a lot of memory – even 1GB+ !!) – but of course cannot be simply rollbacked. I have whole thing is as EXECUTE IMMEDIATE (which allows to adjust hints on a fly) in one stored procedure with detail logging about number of rows inserted… works like a charm even for 100mm+ inserts.

:-)

I tried to use pipelined functions but although it can speed up a lot the whole insert, pipeline functions do not like (if I can use that word) db-limk in parallel. When I ran the inserts in single server, I noticed good improvement, but it went all away with db-link iserts (the main point of this).

By: Pete Scott

Pete Scott — Wed, 10 Dec 2008 17:31:49 +0000

Very timely for me – I am reviewing a data warehouse where a lot of the ETL is built around joins running on remote (source) machines. Coupled with the explain plans I captured and this blog piece I have convinced the customer that they need to rethink how they do this part of their batch process.

I suspect that they (in the long distant past) gave these these troublesome distributed queries to a DBA to tune, and then wrapped the tuned select statements with the insert into and did not notice the change in plan.

By: Jonathan Lewis

Jonathan Lewis — Mon, 08 Dec 2008 21:11:47 +0000

Gary,

I think your final comment about “careful weighing up” applies to all cases of distributed queries and transactions.

I recall cases in earlier versions of Oracle where I could run a (long) distributed nested loop join, and get inconsistent results by changing the data at the remote table as the nested loop was running.

I’m not sure that your example would be an more problematic than not creating the view, by the way – but I’d want to check it before I committed myself.

If you have links that double back like this, I think that (recent versions of) Oracle may detect what’s going on and make the queries tightly-coupled branches of the same transaction. (This wouldn’t handle the VPD / sys_context features necessarily, but they’re likely to behave in unexpected ways anyway)

By: gary

gary — Mon, 08 Dec 2008 04:01:16 +0000

Hi Chris,
I agree that it is an implementation restriction. I don’t think there’s any theoretical reason why it can’t be done. But equally I can see that some-one may look at the existing code and try to work out what needs to be done in terms of read and write consistency, locking, mutating tables, deferrable constraints, multi-table inserts, logging DML exceptions, backwards compatibility, trace, audit etc, and decide its not worth the trouble.

Jonathan’s footnote “you’ll have to create a join view at the remote site” needs careful weighing up.
You create db_link “ab” to go from “a” to “b” and “ba” to go from “b” back to “a”.
In “a” your “session 1″ does a “select * from x@ab”. In “b”, “x” is a synonym for “y@ba”. The actual result from object “y” will be from a separate database session than your original “session 1″. It won’t see any of session 1′s uncommitted changes to the table and may have a different isolation level, sys_context values (VPD), roles enabled, package state…

By: Christian Antognini

Christian Antognini — Sun, 07 Dec 2008 22:41:17 +0000

Hi Gary

> I think they mean that the db where the data is being changed
> must be the “master”/”driving site”.

Yes, this is my understanding as well. But, as I wrote, it does not make sense… or, at least, it could be different ;-)

In the documentation is written “The DRIVING_SITE hint instructs the optimizer to execute the query at a different site than that selected by the database. This hint is useful if you are using distributed query optimization.”

My point is that the DRIVING_SITE hint should not apply to the DML part of a statement but only (as the documentation says) to the query. In a CTAS or INSERT SELECT statement that would mean that the driving site might be on a different databases than the target database (where data is inserted/updated/deleted).

Honestly, I do not see a technical reason why that should not be possible. Take, for example, a plain query executed remotely for which the remote database is also the driving site. Where is sent the output data? Locally. So, why it should not be possible to write that data into a local table instead than sending it back to a client? Once again, I do not see why that should not be possible. Hence, this is an implementation restriction…

Cheers,
Chris