DomainKey-Signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=gamma;        h=mime-version:in-reply-to:references:date:message-id:subject:from:to         :content-type:content-transfer-encoding;        b=Pk1a6sw7VOWjiIeO0+rtBBLj9m8ey1L2nhl90hMscjVYm0FJonJwzSrMYtJmHAZ+sz         GSvyywW5RMFwmbw/z8HFhQcI1bbgzP340rvW3GfPJ0R7gMrBl18zoroRMJC0YzFnlYSE         7IoKAV80jRcKVIqOUiZC+dcDYMRIygpHI6p/0=
MIME-Version: 1.0
In-Reply-To: <5409709395C6884598ADE701EDED9ACD06F65EE4@CINMLVEM17.e2k.ad.ge.com>
References: <5409709395C6884598ADE701EDED9ACD06F65EE4@CINMLVEM17.e2k.ad.ge.com>
Date: Wed, 2 Feb 2011 18:44:36 +0200
Message-ID: <AANLkTinxD+e0jJZ5PferpttJNDkOV3TmmaL5LPyqEpG+@mail.gmail.com>
Subject: Re: Slow performance when upgrading to 11g from 10g
From: Ilmar Kerm <ilmar.kerm@gmail.com>
To: oracle-l@freelists.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: ilmar.kerm@gmail.com

On Wed, Feb 2, 2011 at 6:12 AM, Aragon, Gabriel (GE, Corporate,
consultant) <gabriel.aragon@ge.com> wrote:
> Hi guys,
>
> though I have collected some info on this, I would like to know if there is
> some tips that you can share on same, if after upgrading to 11g you detected
> slow performance on a database that was ok in 10g (same hw),  and if
> possible some stories of success.

We did 10.2.0.4 EE -> 11.2.0.2 EE on Solaris x86_64 upgrade a few
months ago. A few unexpected problems:

1) When using ansi outer joins, 10.2 allowed some columns to be
ambiguously defined in join conditions. Note 1111459.1.
2) If you used in 10g to mass-create one-time DBMS_SCHEDULER jobs,
then in 11.2 you need to set the job_style parameter to LIGHTWEIGHT,
otherwise will hit the following issue with internal SQL (insert into
access$...):
http://www.usn-it.de/index.php/2010/08/04/oracle112-mutex-s-too-many-child-cursors/
Anydata arguments are not supported with lightweight jobs (no error
message, but after some time job execution just stops).

-- 
Ilmar Kerm
--
http://www.freelists.org/webpage/oracle-l