RE: Oracle 11G Upgrade

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 ?



Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
_at_jloracle

________________________________________
From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] on behalf of Dominic Brooks [dombrooks_at_hotmail.com]
Sent: 28 March 2014 14:04
To: rjoralist3_at_society.servebeer.com
Cc: oracle-l_at_freelists.org
Subject: Re: Oracle 11G Upgrade

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

Similarly merge is different again.

http://orastory.wordpress.com/2011/10/13/concurrent-merge


Cheers,
Dominic

Sent from my iPhone

On 28 Mar 2014, at 13:53, "Rich Jesse" <rjoralist3_at_society.servebeer.com> 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
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
--
http://www.freelists.org/webpage/oracle-l


--