Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Background

Updating SAP system kernel releases of your managed systems involves executing the SAP Kernel Update operation. This operation requires stopping the application server instances, resulting in system downtime.

The SAP Kernel Update automation provides a solution to relieve SAP administrators from performing time-consuming tasks, such as establishing connections to the SAP server(s) for patch deployment and the manual stopping and restarting of the SAP system. Automated kernel patching can result in significant reduction in planned downtime for maintenance window and increased security compliance with regular patching.

Kernel Patch Level

Initially, a kernel is internally released at patch level 1 and deployed to internal SAP systems. It undergoes patching as needed, incrementing the patch level (e.g., PL 1, 2, 3, and so on) with each new update.

A customer release occurs a few months later, featuring SAPEXE and SAPEXEDB executables at the running patch level (e.g., SAPEXE_15 and SAPEXEDB_15). Subsequently, patch levels continue to increase incrementally until the first SP Stack Kernel release. These SP Stack Kernels are easily recognizable by being numbered in hundreds (e.g., 100, 200, 300, and so on). For instance, PL 42 can be the last regular patch level, followed by the first SP Stack Kernel release at PL 100.

Regular kernel patches resume at PL 110 (PL 210, 310, and so on), increasing by one with each new patch (e.g., 110, 111, 112, 113, and so on) until the next SP Stack Kernel is introduced.

Patch numbers within the range of 101 to 109, 201 to 209, 301 to 309, and so on, are reserved for emergency corrections specific to the SP Stack Kernel. An emergency SP Stack Kernel at PL 101 includes select fixes on top of the SP Stack Kernel PL 100 and does not incorporate corrections delivered in the regular kernel patch levels (e.g., 110, 111, 112, and so on). Typically, this range remains empty as emergency corrections are infrequent.

The following figure shows a sample numeration within a kernel release:

72x Kernel

The 72x code line supports SAP Business Suite 6.0 (EhP ≤ 6) and is compatible with SAP NetWeaver releases 7.0 to 7.3 EhP1. This code line contains kernel 720, 721, and 722, including their respective variations: EXT and EX2 versions. The EXT and EX2 kernel versions are specifically designed to provide support for more recent operating systems (OS) and database (DB) platforms, as well as newer compiler/runtime environments.

For more details, see 1744209 - SAP Kernel 720, 721, and 722: Versions and Kernel Patch Levels.

74x and 75x Kernel

The 74x and 75x code lines offer support for both SAP Business Suite 6.0 (EhP7 and EhP8) and SAP S/4HANA releases 1511, 1610, and 1709. This compatibility extends to SAP NetWeaver releases 7.4 and 7.5 and SAP NetWeaver Application Server for ABAP 7.51 and 7.52. Within this code line, you'll find a range of kernel versions, from 740 up to the current version 753.

For more details, see 1969546 - Release Roadmap for Kernel 74x and 75x.

77x and 78x Kernel

The 77x and 78x code lines provide support for recent SAP S/4HANA releases from SAP S/4HANA 1809 onwards, including kernel version 773 and subsequent releases.

For more details, see 2907361 - Release Roadmap for Kernel 77x and 78x.

Naming Convention for Kernel Patches

Given a specific patch level, the name of the corresponding kernel patch in the SAP ONE Support portal's download section follows this pattern:

<Package-name>_<Patch-level>-<SAP-internal-GUID-No>.<archext>

where:

  • “<Package-name>” is the name of the corresponding kernel archive such as DW, SAPEXE,

SAPEXEDB, and R3trans.

  • “<Patch-level>” is the patch level.

  • “<SAP-internal-GUID-No>” is a unique ID, which is indicative of a specific kernel release and platform/database combination.

  • “<archext>” is the package format, typically SAR.

Pre-requisite Requirements

  • The system should be registered in IT-Conductor for monitoring.

  • A Robot User should be created and associated with the application/DB/OS users with assigned roles/privileges to execute the local action on the system to be stopped/started.

  • The ownership of the process definition should be assigned to the Robot User.

Scenario

In this demo scenario, we used the lab system CR2 and the kernel 7.22EXT.

Note: The kernels, the IGS for the kernel, and the hostagent were downloaded.

Directories

The file resources are mounted to the server via NFS.

The following is the directory for SAPEXE and SAPEXEDB:

The following is the directory for SAPIGS:

Path Environment Variables

#Variable Path for SAPCAR,Kernel,IGS
path_sapcar=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/
path_kernel=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/7.22_EXT/
path_igs=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/SAP_IGS_7.20_EXT/
patch_backup=/sybase/Kernel/Backup_Kernel_$(date +"%Y-%m-%d").SAR
run_kernel=/usr/sap/$sapsid/SYS/exe/run/

Execution Config

The following is the ExecutionConfig template for the Form.SAP-Linux-KernelUpdate:

Process Definition

The following is a sample process definition for the SAP Kernel Update:

Vladimir Mokrushov is there an actual process definition (with colored activities) that we can show here instead? Similar to automation documentation.

Form

The following is a sample form for the SAP Linux Kernel Update automation:

Bash Script

The following bash script executes the SAP Kernel Update operation:

#Variable from IT-Conductor
synr=$[context/ExecutionConfigCustom.Properties::APPSAP=>SAP.SYSTEM_NUMBER]
sapsid=$[context/ExecutionConfigCustom.Properties::APPSAP=>SAP.SID]
patchlv=$[context/ExecutionConfigCustom.Properties::PATCHLEVEL]
igspatchlv=$[context/ExecutionConfigCustom.Properties::IGSPATCHLEVEL]
dbtype=$[context/ExecutionConfigCustom.Properties::APPSAP=>SAP.RFCDBSYS]
###
#Variable Path for SAPCAR,Kernel,IGS
path_sapcar=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/
path_kernel=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/7.22_EXT/
path_igs=/mnt/software/SAP/SAP_KERNEL_64-BIT_UNICODE/SAP_IGS_7.20_EXT/
patch_backup=/sybase/Kernel/Backup_Kernel_$(date +"%Y-%m-%d").SAR
run_kernel=/usr/sap/$sapsid/SYS/exe/run/
###
#Variable Kernel name
lin_indp=70000596
lin_db2=70000593
lin_maxdb=70000594
lin_oracle=70000595
lin_ase=70000607
lin_hana=70000612
####
#Vaiable IGS Kernrl OS
igs_lin=20007790
####
#Check DB for Kernel
if [ "$dbtype" = "SYBASE" ]; then lin_db=$lin_ase; fi
if [ "$dbtype" = "ORACLE" ]; then lin_db=$lin_oracle; fi
if [ "$dbtype" = "HDB" ]; then lin_db=$lin_hana; fi
if [ "$dbtype" = "DB6" ]; then lin_db=$lin_db2; fi
count1=0
#Check SAPCAR
file_name1=$path_sapcar"SAPCAR"
if [ -f $file_name1 ]; then count1=$((count1+1)); else echo "$file_name1 does not exist."; fi
#Check File Database independ
file_name2=$path_kernel"SAPEXE_"$patchlv-$lin_indp".SAR"
if [ -f $file_name2 ]; then count1=$((count1+1)); else echo "$file_name2 does not exist."; fi
#Check File Database depend
file_name3=$path_kernel"SAPEXEDB_"$patchlv-$lin_db".SAR"
if [ -f $file_name3 ]; then count1=$((count1+1)); else echo "$file_name3 does not exist."; fi
#Check File IGS
file_name4=$path_igs"igsexe_"$igspatchlv-$igs_lin".sar" 
if [ -f $file_name4 ]; then count1=$((count1+1)); else  echo "$file_name4 does not exist."; fi
#Check if All files Present
if [ "$count1" -ne "4" ]; then exit 1; fi 
####
#For Debug
#echo $file_name4
#echo $count1
###
# Stop SAP & Host Agent
sapcontrol -nr $sysnr+0 -function StopSystem 
sapcontrol -nr $sysnr+1 -function StopSystem
sapcontrol -nr $sysnr+0 -function StopService
sapcontrol -nr $sysnr+1 -function StopService
###
#Backup Old Kernel
echo "Starting Backup Old Kernel...."
echo "$file_name1 -cf $patch_backup -R $run_kernel*"
$file_name1 -cf $patch_backup -R $run_kernel*
###
#cd /usr/sap/$sapsid/SYS/exe/run/
#echo $(pwd)
#echo rm -rf *
rm -rf /usr/sap/$sapsid/SYS/exe/run/*
###
#Start patch Kernrl
echo "Starting Path Kernel...."
#echo "$file_name1 -xf $file_name2 -R $run_kernel"
#echo "$file_name1 -xf $file_name3 -R $run_kernel"
#echo "$file_name1 -xf $file_name4 -R $run_kernel"
$file_name1 -xf $file_name2 -R $run_kernel
$file_name1 -xf $file_name3 -R $run_kernel
$file_name1 -xf $file_name4 -R $run_kernel
###
# Start Host Agent & SAP
sapcontrol -nr $sysnr+0 -function StartService $sapsid
sapcontrol -nr $sysnr+1 -function StartService $sapsid
sapcontrol -nr $sysnr+0 -function StartSystem
sapcontrol -nr $sysnr+1 -function StartSystem

Test Execution

Demo Scenario

Show the original version of the Kernel and IGS (Problem: In ITC there is only the Kernel version without a patch number, there is no IGS version)

Сheck in the SAP system

Kernel:

IGS:

tail -20 /usr/sap/CR2/DVEBMGS00/igs/log/mux_ozsapcrm2.trc

The file resources are mounted to the server via NFS.

The following is the directory for SAPEXE and SAPEXEDB:

The following is the directory for SAPIGS:

Start Kernel Update

OZSoft Dashboard for SAP Kernel Patching

Check the updated version of the Kernel and IGS

Kernel:

IGS:

  • No labels