Too many heap subpools might break the upgrade
Posted
by Mike Dietrich
on Oracle Blogs
See other posts from Oracle Blogs
or by Mike Dietrich
Published on Wed, 29 Jun 2011 04:00:54 -0700
Indexed on
2011/06/29
16:27 UTC
Read the original article
Hit count: 281
/Oracle/Best Practice
Recently one of our new upcoming Oracle Database 11.2 reference customers did upgrade their production database - a huge EBS system - from Oracle 9.2.0.8 to Oracle Database 11.2.0.2. They've tested very well, we've optimized the upgrade process, the recompilation timings etc.
But once the live upgrade was done it did fail in the JAVA component piece with this error:
begin if
initjvmaux.startstep('CREATE_JAVA_SYSTEM') then
*
ORA-29553:
classw in use: SYS.javax/mail/folder
ORA-06512: at "SYS.INITJVMAUX", line 23
ORA-06512: at line 5
Support diagnosis was pretty quick - and refered to:
Bug 10165223 - ORA-29553: class in
use: sys.javax/mail/folder during database upgrade
But how could this happen? Actually I don't know as we have used the same init.ora setup on test and production. The only difference: the prod system has more CPUs and RAM. Anyway, the bug names as workarounds to either decrease the SGA to less than 1GB or decrease the number of heap subpools to 1. Finally this query did help to diagnose the number of heap subpools:
select count(distinct kghluidx) num_subpools from x$kghlu where kghlushrpool = 1;
The result was 2 - so we did run the upgrade now with this parameter set:
_kghdsidx_count=1
And finally it did work well.
One sad thing:
After the upgrade did fail Support did recommend to restore the whole database - which took an additional 3-4 hours. As the ORACLE SERVER component has been already upgraded successfully at the stage where the error did happen it would have been fine to go on with the manual upgrade and start catupgrd.sql script. It would have been detected that the ORACLE SERVER is upgraded already and just picked up the non-upgraded components.
The good news:
Finally I had one extra slide to add to our workshop presentation
© Oracle Blogs or respective owner