RE: Oracle 11G Upgrade

From: Jonathan Lewis <>
Date: Fri, 28 Mar 2014 16:29:41 +0000
Message-ID: <CE70217733273F49A8A162EE074F64D901DE664A_at_exmbx05.thus.corp>

Good point - and that's just scratching the surface.

But the focus on the concurrency raises another couple of issues for the OP.

1) How is the data generated for the 30 concurrent processes - perhaps the data sets that each process gets are now in a different order because of (e.g.) a change in the execution plan of the query that generated the data; such a change might introduce contention that didn't previously exist.

2) Locking (especially relating to tables with RI) has changed a few times between 9i and 11g - is it possible that processes are spendng time waiting for locks that they didn't have to worry about in 9i ?

Jonathan Lewis

From: [] on behalf of Dominic Brooks []
Sent: 28 March 2014 14:04
Subject: Re: Oracle 11G Upgrade

"Update else insert" behaves differently than "insert else update" under concurrent activity.

Similarly merge is different again.


Sent from my iPhone

On 28 Mar 2014, at 13:53, "Rich Jesse" <> wrote:

>> Jack, have you considered just changing the logic to perform the update
>> first and check the cursor count number of rows updated.  If zero perform
>> the insert.
> An INSERT, followed by an UPDATE on fail should be more efficient.  I can't
> remember where I saw that years ago (asktom?), but my own testing confirmed
> it in some older version of Oracle (9 or 10).
> I was thinking along the same lines though and wondering if a MERGE
> statement in place of the INSERT/UPDATE would work...
> Rich
> --

-- Received on Fri Mar 28 2014 - 17:29:41 CET

Original text of this message