Skip to Content

If you been installing an SAP CE 7.2 system on an 32-Bit Windows Server on a Amazon Web Service cloud system but failed upgrading it to SP03 then this blog is for you. The reason the upgrade initially fails is, because the kernel upgrade fails upgrading certain dlls and you will se the following error message:

!http://www.schuler-web.de/blog/kernel.jpg|height=405|alt=Upgrading certain dlls fails|width=405|src=http://www.schuler-web.de/blog/kernel.jpg|border=0

However, if you were able to solve this, you would run into another problem that is caused by insufficient Java heap memory due to a formula to calculate this type of memroy that is unsuited for a 32-Bit Windows Server Amazon Web Service cloud installation and you will see the following error message:

!http://www.schuler-web.de/blog/crash.jpg|height=405|alt=The J2EE server crashed during the upgrade|width=405|src=http://www.schuler-web.de/blog/crash.jpg|border=0

Having a look into the developer trace of the J2EE server process would reveal that in fact it ran out of memory:

!http://www.schuler-web.de/blog/trace.jpg|height=258|alt=The developer trace of the J2EE server process shows the problem|width=220|src=http://www.schuler-web.de/blog/trace.jpg|border=0!

So lets change this and two other parameters that could prevent the upgrade from beeing successfull and start the installation all over again. Start the Config Tool:

!http://www.schuler-web.de/blog/configtool.jpg|height=300|alt=Start the Config Tool|width=400|src=http://www.schuler-web.de/blog/configtool.jpg|border=0!

In the Config Tool navigate to cluster-data -> template -> instance and chose the tab for the VM Parameters. There you see the unsuited calculation. To change this enter 1024 as the Custom Value for the maxHeapSize parameter:

!http://www.schuler-web.de/blog/heapsize.jpg|height=375|alt=Extend the maximal allowed heap size|width=425|src=http://www.schuler-web.de/blog/heapsize.jpg|border=0!

Then navigate to cluster-data -> template -> services -> classpath_resolver and set 256 as the value for javac.Xmx, which is the heap size for the Java compiler:

!http://www.schuler-web.de/blog/javac.jpg|height=375|alt=Set the heap size for the java compiler|width=425|src=http://www.schuler-web.de/blog/javac.jpg|border=0!

Save your change and restart the cluster as the Config Tool tells us to do.

Next we have to adjust the cache size of the MaxDB database. For this launch the Database Manager, navigate to Configuration -> Parameters and change the CacheMemorySize parameter to 8192:

!http://www.schuler-web.de/blog/cache.jpg|height=360|alt=Reduce the database cache|width=576|src=http://www.schuler-web.de/blog/cache.jpg|border=0

Now we can (re-) start the upgrade. To do so start the SAP Java Support Package Manager (JSPM):

!http://schuler-web.de/blog/go.jpg|height=300|alt=Start JSP via go.bat|width=400|src=http://schuler-web.de/blog/go.jpg|border=0!

Login as administrator or user <SID>adm. (Your SAP CE 7.2 J2EE server has to be up and running for this.) If you loged in as administrator JSPM would complain that you should login as user <SID>adm but in fact it makes no difference for the upgrade:\J00\j2ee\JSPM\tmp\newKernel_01\kernel) to the actual kernel directory (D:\usr\sap\CE1\<SID>+\exe\uc\NTI386) did not work. While not knowing the reason for this problem, we don’t bother but just copy the new kernel manually. When being asked whether to replace an existing file we do so and also for all other occasions:</p><p> !http://www.schuler-web.de/blog/replace.jpg|height=214|alt=Replace all files with their upgrades versions|width=228|src=http://www.schuler-web.de/blog/replace.jpg|border=0!</p><p>During the copying we run into the same problems as JSPM:</p><p>!http://www.schuler-web.de/blog/icutd34.jpg|height=148|alt=Blocked files|width=243|src=http://www.schuler-web.de/blog/icutd34.jpg|border=0!</p><p>We cancel the copying, rename the original file, in this case icudt34.dll to icudt34.dll.del:</p><p>!http://www.schuler-web.de/blog/rename.jpg|height=300|alt=Rename all blocked files and copy again|width=400|src=http://www.schuler-web.de/blog/rename.jpg|border=0! </p><p>and start the copying again. We repeat this until the kernel is fully upgraded. We then proceed with JSPM and after a couple of hours and some automatic restarts of the SAP J2EE server the upgrade fineshed successfully:</p><p>!http://www.schuler-web.de/blog/complete.jpg|height=405|alt=JSPM completed the upgrade|width=405|src=http://www.schuler-web.de/blog/complete.jpg|border=0!</p><p>With this we got an mostly up-to-date SAP CE 7.2 system in the cloud. However be aware that there are already quite a few patches available for CE 7.2 SP03. Therefore, if you run into a strange problem with CE 7.2 SP03, check for those patches.</p>

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Martin English
    FWIW, I had similar problems when upgrading CE7.1 to SP03 for a recent xMii rollout.  The systems were being installed on x64 Wintel systems running on a vmware-type platform.  Basically, I ended up following the same process as you, from the update of the JSPM.

    The point being, Amazon, by providing an Infrastructure as a Service environment, provides complete control over the Amazon Image, so you can adjust it to make it as identical as possible to the production environment.

    (0) 
  2. Frank Schuler Post author
    Reproducably the Microsoft patch KB2345886 has been preventing one of our SAP CE 7.2 SP03 systems from starting. The SAP CE 7.2 SP3 system runs on top of a x86-based versions of Windows Server 2003 SP2. Please check KB2345886 on MSDN for more details concerning this patch and whether you need it.
    (0) 

Leave a Reply