SAP kernel patching: a practical guide

The SAP kernel is the set of native executables every ABAP system runs on: disp+work, the message server, the enqueue server, sapstartsrv, igswd and the rest. It sits below the ABAP stack and gets patched far more often than most teams patch it. This is a practitioner's guide: what a kernel patch actually swaps, the exact commands to read and change the level, how a rolling switch keeps a multi-instance system available, and why tracking kernel and DBSL levels across a landscape matters more than any single patch.

What "patching the kernel" actually swaps

A kernel patch replaces the binaries in the instance executable directory with a newer patch level of the same kernel release (occasionally a higher release, which is a bigger exercise). It is not a Support Package and not a release upgrade. The ABAP repository, the data dictionary and the database content stay exactly where they are. You are replacing the engine, not the cargo. SAP ships kernel patches roughly monthly to fix security defects, crashes and performance regressions, which is why a system nobody has touched for a year is routinely 30–60 patch levels behind.

Three numbers describe where a system sits, and they drift independently:

Reading where a system sits today

Before touching anything, record the current level so you have a rollback reference. As <sid>adm on the host:

# Full kernel + DBSL banner (run from the executable directory or with it on PATH)
disp+work -V | head -40

# Just the numbers that matter, without the noise
disp+work -V | grep -E "kernel release|patch number|DBSL"

# From sapstartsrv without stopping anything (works remotely too)
sapcontrol -nr <nr> -function GetVersionInfo

A typical banner reports the release (kernel release 7.89), the patch number (patch number 401), the compilation details, and the DBSL version. In-system, SM51 shows the kernel level per instance and DIR_EXECUTABLE tells you which directory is in play; a disp+work -V from the OS is the ground truth when the two disagree.

Getting the right packages

Most of the work, and most of the mistakes, comes down to choosing the correct combination. A kernel patch is two SAR archives that must match the release, OS/architecture and database:

Download both at the same patch level, plus a current SAPCAR to unpack them, because an old SAPCAR cannot always read a newer archive. Stage them in a scratch directory and list before extracting:

# One SAPCAR unpacks the rest; keep it outside the kernel dir
./SAPCAR -tvf SAPEXE_401-70006642.SAR      # list, do not extract yet
./SAPCAR -tvf SAPEXEDB_401-70006642.SAR

# Verify the SAP signature on the archive where your SAPCAR supports it
./SAPCAR -tVf SAPEXE_401-70006642.SAR

The single-system procedure

On a one-instance system a kernel patch means downtime for the duration of a clean stop, swap and start. The order that keeps you safe:

# 1. As <sid>adm: stop the instance cleanly and confirm it is down
sapcontrol -nr <nr> -function Stop
sapcontrol -nr <nr> -function StopService
sapcontrol -nr <nr> -function GetProcessList   # expect GRAY / stopped

# 2. Back up the CURRENT kernel so a rollback is a directory swap
cd /usr/sap/<SID>/SYS/exe/uc/<platform>        # the shared exe, or the instance 'run' dir
cp -rp . /usr/sap/<SID>/kernel_backup_$(date +%F)

# 3. Extract the new kernel OVER the executable directory
SAPCAR -xvf /stage/SAPEXE_401-*.SAR
SAPCAR -xvf /stage/SAPEXEDB_401-*.SAR

# 4. Fix ownership + setuid bits (the step people forget), as root
su - root -c "cd $(pwd) && ./saproot.sh <SID>"

# 5. Start and watch it come up
sapcontrol -nr <nr> -function StartService <SID>
sapcontrol -nr <nr> -function Start
sapcontrol -nr <nr> -function GetProcessList   # expect GREEN

The back-up-the-old-kernel step is the one people skip and regret. A kernel rollback is fast and safe only if the previous binaries are still on disk. Restoring from a system backup at 02:00 is not the same thing.

After extraction the executables are owned by whoever ran SAPCAR and have lost their setuid flags; saproot.sh restores root-owned setuid on icmbnd, correct ownership on saposcol, and so on. Skip it and you get processes that start but cannot bind privileged ports or attach shared memory.

Minimising downtime: the rolling kernel switch

On a system with several application servers you can do far better than a full outage. Patch one dialog instance at a time while the others carry the load; the central services, meaning the message and enqueue servers in the (A)SCS, need their own short window, which in a properly built HA cluster is covered by the enqueue replication server (ERS) failover.

Per dialog instance the sequence is:

# 1. Drain users off the instance first
#    SMLG: remove the instance from its logon groups so new logons avoid it

# 2. Stop just this instance
sapcontrol -nr <nr> -function Stop

# 3. Extract SAPEXE/SAPEXEDB into this instance's exe dir, then:
su - root -c "./saproot.sh <SID>"

# 4. Start it and confirm GREEN before moving on
sapcontrol -nr <nr> -function Start
sapcontrol -nr <nr> -function GetProcessList

# 5. Put the instance back into its logon groups (SMLG)

Repeat instance by instance, then take the short (A)SCS window. This rolling pattern is what SAP calls a rolling kernel switch (RKS). The exact ordering, and whether the central-services window is truly zero-downtime, depends on your release and how the HA cluster is wired, so validate the sequence against your setup rather than following a generic runbook to the letter.

Validation after the patch

"It started" is not "it worked". Confirm the level actually moved and nothing regressed:

# The number changed?
disp+work -V | grep -E "patch number|DBSL"

# All work processes up, nothing restart-looping?
sapcontrol -nr <nr> -function GetProcessList
#   in-system: SM50 (work processes), SM51 (instances + kernel per instance)

# Nothing new in the logs in the first hour?
#   SM21  : system log
#   ST22  : ABAP dumps (watch for new signatures)
#   dev_w* / dev_disp in the work directory : startup traces

Pay special attention to the DBSL. A kernel that starts but writes database-library warnings to dev_w0 is a patch that is not finished, because the DBSL and the database client must agree. On HANA, confirm the dbhdbslib line in disp+work -V matches the patch you intended.

Why tracking levels across the landscape matters

The hard part of kernel hygiene is not patching one system. It is knowing, across twenty systems, which are behind, by how much, and whether DEV, QAS and PRD are even on the same level. Patch-level drift between environments is where "it worked in QAS" turns into a production surprise, because a fix or a behaviour change rode in on a kernel patch that PRD never received. A monitoring layer that reads the kernel release, kernel patch level and DBSL per system turns that from a manual disp+work -V tour into a single view.

This is where Farrenio fits today. The platform reads the kernel release and patch level (from the same disp+work output you would check by hand) and the DBSL level, and surfaces them per system across the estate alongside SPAM/SAINT versions, so before a patching campaign you can see exactly what each system is carrying and which ones are overdue. The SAP Basis monitoring page covers the wider set of signals.

Executing the kernel patch itself, as a guided rolling update driven from the platform, is on our roadmap rather than shipped today, and we would rather say so plainly. What is automated now is documented on the SAP Basis automation page: client copy, client deletion and instance lifecycle.

A short checklist

• Record the current level (disp+work -V) before you start, because that is your rollback reference.
• Match SAPEXE + SAPEXEDB to release, OS/architecture and database, at the same patch number.
• Back up the current executable directory every time. Rollback is a directory swap, not a restore.
• Always run saproot.sh as root after extraction, or you get processes that start but cannot bind or attach shared memory.
• Patch non-production first and let it sit long enough to surface problems before PRD.
• On multi-instance systems, roll one dialog instance at a time and take a single short (A)SCS window.
• Validate the reported patch and DBSL level and watch SM21 and ST22. Do not just confirm the instance came up.
• Keep DEV, QAS and PRD within a sensible patch-level distance of each other.