Upgrading SAP Kernel from Release 700 to SAP Kernel 720_REL / 720_EXT Part I of II
This blog features “How to upgrade SAP Kernel from 700 to 720 (720_REL or 720_EXT)”
Upgrading SAP Kernel (Release Upgrade from 700 to 720) is pretty much straight forward, if you stick to and follow the Master SAP Note: 1636252 – Installing a 7.20 kernel in SAP Web AS 7.00/7.01/7.10/7.11.
For the most part, the upgrade is pretty much similar to applying a Kernel patch without changing the Release, But I thought to rather write a blog post, to layout the epitome and crucial differences as compared to while applying a Kernel patch. And this being my first blog at SCN, so please bare with me in case you feel the blog is not up to the mark as it should be. And of course, I warmly welcome your feedback and suggestions.
So here is the basic overview of the system, before i shoot right into going about upgrading SAP Kernel.
|Operating System||Red Hat Enterprise Linux 5.2|
|Database Client Library||Oracle Instant Client 10.2.0.5|
|SAP Solution||SAP NetWeaver 7.0 Java App. Server hosting Enterprise Portal|
|Source Kernel||SAP Kernel 700_REL 64 BIT UNICODE Patch 353|
|Target Kernel||SAP Kernel 720_REL 64 BIT UNICODE Patch 401|
Before beginning, I would like to break this blog in sections, in and around “Kernel 720” so as to get to know other things as well besides just the technical upgrade. I would be covering the following:
- SAP Kernel 720_REL vs 720_EXT? Which SAP Kernel Release 720 should I use?
- Benefits of using SAP Kernel 720?
- SAP Notes relevant for upgrading to SAP Kernel 720
- Upgrading the Kernel (You could just directly scroll down to this section, for Quick How to? 😛 )
- Follow-up Activities
SAP Kernel 720_REL vs 720_EXT? Which SAP Kernel Release 720 should I use?
The very first thing that you have to decide while upgrading the Kernel to 720 is, which 720 Kernel to be used? Kernel 720_REL or 720_EXT?
OK, so first let’s try to figure out what are these two kernels, what are the differences and which one should be used?
Kernel 720_REL is the standard SAP Kernel, which is downward compatible with older versions of operating systems and database clients. Basically this SAP Kernel was compiled on older versions of OS Compilers and linked to older database client libraries.
Whereas, Kernel 720_EXT is the new extended kernel, which is released for recent OS releases and database clients. Also, it does not support older versions of operating system platforms.
For supported OS & DB releases for Kernel 720_EXT, please check the SAP Note 1553301 – 7.20 EXT Kernel – Usgae
If your platform meets the requirements for Kernel 720_EXT, it’s recommended to go for 720_EXT rather than 720_REL.
For Linux, as my operating system RHEL 5 is not supported for SAP Kernel 720_EXT, I will rule out the usage of 720_EXT and hence my target SAP Kernel would be 720_REL. Of course, if I am very keen to use Kernel 720_EXT rather than 720_REL, I do need to upgrade my Operating System first to RHEL 6, which I think I would take it up some other time, but certainly not right now 😏 .
Supported Linux Versions for SAP Kernel 720_EXT are: Red Hat Linux 6, SuSE Linux 11 & Oracle Linux 6. Similarly you could check for your corresponding operating system, and decide on which Kernel 720 type to be used.
Benefits of Using SAP Kernel 720
I won’t talk about the mo-jo-jo of SAP Kernel 720, and how is it a game-changer over SAP Kernel 700.
To put simply, you should upgrade from SAP Kernel 700 to 720 because:
- The very obvious, Support of SAP Kernel 700 has ended on 31st August 2012 and now it is replaced by SAP Kernel 720
- Kernel 720 supports Rolling Kernel Switch – What it means for you is that, you can minimize the downtime of SAP system while applying Kernel Patches
- Kernel 720 has got Flexible License Generator – What it means for you is that, License is not linked to the hardware key anymore, thus allowing you to move your SAP systems to another hardware ensuring High Availability.
- Kernel 720 supports SAP GUI for HTML with Unified Rendering – What it means for you is that, you can access SAP System (ABAP per se) on a WEB Browser as a WEBGUI without the need for Installing SAP GUI.
- In Kernel 720, the security has been enhanced via Access Control Lists (ACLs) – What it means for you is that, you should be running SAP with enhanced security. Powerful thought! 😛
- Kernel 720 provides optimized performance via profile based optimization on UNIX platforms.
SAP Notes relevant for upgrading to SAP Kernel 720
You would like to keep the following SAP Notes handy for the Kernel Upgrade:
- 1636252 – Installing a 7.20 kernel in SAP Web AS 7.00/7.01/7.10/7.11
- 1629598 – SAP Kernel 720 will replace older kernel versions
- 1610716 – Correcting run-time objects with incorrect alignment
- 1563102 – Linux Requirements for 7.20 EXT and higher kernel (Alternatively, you can refer the below generic note for all OS)
- 1553301 – 7.20 EXT Kernel – Usage
- 1031096 – Installing Package SAPHOSTAGENT
- 19466 – Downloading SAP kernel patches
Upgrading the Kernel
Without any further delay, let’s get straight to the business now:
Get a latest version of SAP Note 1636252, and perform steps applicable for your platform. Below are the steps that I have done specific to my platform.
For Java only systems, check the following:
1) For release 700, there is a incompatibility with jmon, which is eliminated with SAP Java Technology S Offline Component (SAPTECHF.SCA). For release 700, SAP TECH S 700 OFFLINE SP14 PL24 is required:
This is on Higher level.
2) For release 700, the tool JSPM must have at least SP 24:
1) Oracle Database: Oracle 10.1 is not supported with the SAP Kernel 7.20. Needs at least Oracle 10.2
2) Oracle Client Library: Oracle Instant Client 11g is required by SAP Kernel 720_EXT.
This is not applicable for this case as Kernel is 720_REL
Download Required Components / Patches
Download the following from SAP Service Market Place:
- Latest SAPCAR Tool
- SAP Kernel 720_REL 64 BIT UNICODE Latest Patch (DB-INDEPENDENT & DB-SPECIFIC Kernel Files)
- SAP IGS 7.20 (If you have IGS installed, and your target Kernel would be 720_REL)
- SAP IGS Helper (SAP IGS Fonts and Textures, though an optional component, it is recommended to install if you are upgrading to Kernel 720_REL or 720_EXT.
- DBA Tools Package from the Kernel Download Path of DB Specific section
- SAPHOSTAGENT (The SAP OS Collector, onward’s Release 7.20)
SAPCAR Tool =>
SAP KERNEL 720_REL 64 BIT UNICODE Latest Patch =>
SAP IGS 7.20 (Internet Graphics Server) =>
Check if IGS is installed (should be as a Software Component / Development Component)
DBA Tools Package for Oracle 10g and 11g =>
SAPHOSTAGENT (The SAP OS Collector onward’s release 7.20) =>
Stop the SAP System (No need to stop the Database)
Stop SAPOSCOL, assuming that your SAP system release is 700, SAPOSCOL is installed under SAP Kernel.
If the SAP Kernel is added to your path, you can directly execute below command:
Stop processes “SAPSTARTSRV”
Remove any IPC objects that may exist: cleanipc <Instance Number> remove
Now as the SAP OS Collector has been stopped, and IPC has been cleaned up, you can install SAPHOSTAGENT 720, which in turn will update SAPOSCOL and deploy under path /usr/sap/hostctrl/exe/
Extract SAPHOSTAGENT.SAR somewhere on a temporary directory (Note: You should use the latest download SAPCAR tool for extracting all the packages)
You should do the extraction using root, or ensure that the extracted contents belong to root ownership.
The extracted archive will contain saphostexec program
Start the installation of SAPHOSTAGENT as per below:
Subsequent to this, you will see that SAP OS Collector saposcol is now installed under /usr/sap/hostctrl/exe/ onward’s Kernel 720
Install SAP Kernel 720
Well, the most awaited precious step has arrived now 😏
But, you wouldn’t be rushing up, without taking a backup of the current working Kernel before upgrade! Would You? 😎
Take a backup of the existing Kernel 700, from the Global Kernel directory (/sapmnt/<SID>/exe/) and also of Local Instance Specific Kernel Directories (/usr/sap/<SID>/<Instance>/exe/)
Now, switch to directory /sapmnt/<SID>/exe/ with user <sid>adm
Save the following Files & Directories to another path to be used later:
- Directory jvm or sapjvm* if it exists
- File protect.lst if it exists
- Files rfcexec, rfcexec.sec if it exists
- ICU Libraries (*libicu*), if they exist.
Now, switch to user root and change the owner of all files/directories to <sid>adm as shown below:
Now, delete all the files from the kernel directory, including the sub-directories. This ensures that there are no remaining files from the earlier release, which have different name in release 7.20 or are in a different place in a sub-directory.
Now extract the new Kernel (using the latest SAPCAR tool) in /sapmnt/<SID>/exe/ as shown below:
Extract the DBA Tools Package now, as shown below:
Extract IGS Packages now, as shown below:
Now, you need to restore the files to the current directory, which you saved earlier:
- Directory jvm or sapjvm* if copied
- File protect.lst if copied
- Files rfcexec, rfcexec.sec if copied
- ICU Libraries (*libicu*), if copied
To, deploy the optional IGSHELPER.SAR file, switch to the relevant local directory /usr/sap/<SID>/<INSTANCE> on every instance and execute the below command:
I think I have exceeded the max. no of images per blog post, as I cant upload any more images 😯
I Guess, I will have to extend this to Part – II
Nice blog Akshay! Keep it up 🙂
Thanks a lot, Tufyl.
Usefull Information with step-by-step processes..
Thankyou Akshay... 🙂
Thanks Srikanth, for your kind words!
For sharing step by step information.
I am glad to be of help!
You are most welcome!
Please explain How can downtime be reduced:-
"Kernel 720 supports Rolling Kernel Switch - What it means for you is that, you can minimize the downtime of SAP system while applying Kernel Patches"
Regarding the Rolling kernel switch feature, also known as RKS, it is beneficent in case of an SAP system with large no. of application servers or instances.
Basically when you apply kernel patches, you do that on central instance and then replicate the kernel on to all of the application servers, so during the patch application all of the app. servers are unavailable hence the downtime.
Now, this downtime can be further reduced by the following strategy of RKS:
1) It's imperative that kernel patch levels of all application servers must be at same level to communicate without any unexpected disruptions.
2) Suppose you are going from patch level x to y (y >x), you have to first figure out that if some of the application servers on patch x will be compatible with other app. servers at patch level y.
3) Once, you are good to go, you don't patch the kernel of all application servers simultaneously i.e. you bring down one app server, patch it, during this time your SAP system is still accessible. As you are patching the application servers in turn but not in on go, hence the name rolling kernel switch.
4) Then at the right moment, you patch the Central Instance and adjust everything, this is the downtime (shorter than patching everything at one shot)
However there are some pre-requisites for applying RKS mechanism.
I suggest you check out the RKS note Note 953653 - Rolling kernel switch for further details.
Thanks for response.
1) To replicate kernel in application server is done by file 'sapcpe' which comes with kernel executables.
2) If you are having Message server & enq server in central instance... Then this concept defends.
Yes, that's very well correct.
You got that down right.
Thanks for this Blog, it realy helped me in upgrade knowledge. 🙂
I just have a question, if the upgrade is not done in correct way,
how can upgrade impact SAP system? Will impact be too much
after upgrade what things should i look to validate that upgrade is done sucesfully without any impact?
If you follow what is to be followed as per the SAP Notes, then there is very less to minimum chance of things going wrong, as this is pretty much standard process and lot of customer base follows the exact same framework.
However, if you still have a doubt, I would say that just keep a backup of your old kernel for sometime until you are sure that upgrade was A-Ok. Also, after the upgrade once you start the SAP System, all of the SAP Executables/Libraries load-up that were shipped with the new kernel. If there would be a problem, it will hit you right away here.
If you are able to to bring up the system post-upgrade and login and perform some quick transactions that would be all. However in Productive scenarios, the upgrade follows the DEV=>QA => PRD path, so you wont be in trouble of overlooking the upgrade validation..
Run few System Performance/ Checks Transactions in the SAP system post upgrade to validate everything i.e. SICK, DB02, ST03 and likewise.
Thanks for the Detailed information .....nice blog...
Keep posting .....
very usefull information!
Just would like to know one more thing, for Java 700 system is there any other way to find out which Kernel version we have installed?
what I would like to know is if there is any other option (besides using "disp+work") to check witch kernel version we have installed (for example using "nwa" or "index.html").
System Information. There you can hopefully see the Kernel Details.
I have scenario that need your suggestion.
We typically, deploy SPs/EHPs along with default Kernel release with the SP/EHP binaries. However, once we are done with DEV environment, we will then go back to Service Market Place and download the latest kernel release binaries.
B'coz of this approach, we always, end-up in replacing the kernel manually which certainly require extended downtime. Thus, I am looking for your suggestion that, how/what do i replace the old kernel binaries and make the stack XML modification so that with the SUM tool itself I shall be able to deploy the latest kernel.
This way, I can avoid manual deployment of latest kernel after SUM tool completes the SP/EHPs deployment.