Updating the SAP kernel using the rolling kernel switch

Edit online

The SAP rolling kernel switch (RKS) is a method that allows you to upgrade your SAP kernel patch level while the SAP system stays available. Therefore, it is the preferred method for kernel updates in SAP systems that require the highest level of availability. A prerequisite for using a rolling kernel procedure is that the SAP central services run as separate instances. The older central instance concept is not supported.

A general overview of the procedure can be found in the SAP documentation Rolling Kernel Switch (RKS). More details are contained in the central SAP note that describes prerequisites and the manual and automated variants of the rolling kernel switch: SAP Note 953653: Rolling kernel switch.

Manual rolling kernel switch with SAP kernels 7.2x

To avoid loss of enqueue locks during the RKS, this variant of the RKS requires that enqueue replication is active and that an SA z/OS® policy for the SAP central services is active.

Enqueue replication must either be implemented running the central services with EnqCF replication (see Enqueue replication into a IBM Z coupling facility) or with a separate enqueue replication server. Furthermore you need to ensure that the sapcpe mechanism is implemented as recommended by SAP.

Different SAP kernel levels can only be active in the same SAP system if they are compatible. SAP maintains the information which kernels are compatible in the (Statement of Compatibility) file StoC.xml, which is needed in the rolling kernel switch procedure (see SAP Note 953653: Rolling kernel switch).

If a kernel patch is compatible with its predecessor, the kernel patch can be installed and activated in a rolling fashion by first restarting the central services and then one application server instance a after the other, rather than shutting and restarting the complete SAP system.

If SAP Central Services are managed by SA z/OS, then you should perform the RKS as follows:

  1. Save the current kernel level(s).
  2. Install the new kernel in the global SAP exe directory for the application servers and for the SAP Central Services.

For SA z/OS managed ASCS, then perform the following:

  1. If you are running a separate ERS instance: Stop the ERS instance (enqueue replication server) in SA z/OS with the option RESTART = YES.
  2. After successful completion, stop the ASCS instance (enqueue and message server) in SA z/OS with the option RESTART = YES.

Before restarting an SAP application server instance, you should first use SAP transactions to quiesce all SAP workload before restarting the instance. If an SAP application server instance is managed either via SA z/OS or via SA MP, use the automation software to stop and restart the instance

Note: If SAP instances have the SAP HA Interface activated (see SAP HA Interface for SA z/OS), the SAP administrator can use standard SAP mechanisms (SAP MC or the SAP command line tool sapcontrol) to stop and restart the instances.

Automated rolling kernel switch with SAP kernels 7.4x

With SAP kernels 7.4x, SAP has significantly enhanced the RKS procedure, which can now run in a fully automated fashion, requiring no manual input from the SAP administrator after it is started.

When the automated procedure stops and restarts all SAP instances in sequence, the central services instance is stopped and restarted first and afterward the application server instances are stopped and restarted one after another. For a flow diagram, see the SAP documentation that is referenced in SAP Note 953653: Rolling kernel switch.

With 7.4x, the compatibility level of different SAP kernel levels is no longer checked by using an external xml file, but is a property of the SAP kernel itself. The automated RKS procedure checks these levels as part of its operation. For prerequisites and procedures, refer to SAP Note 953653: Rolling kernel switch and the 7.4x SAP Help documentation that is referenced in this SAP note.

The automated RKS can only be started for an SAP system with a redundant setup: the system must have been installed with SAP Central Services and must be running with active replication. In addition, there must be at least two application server instances, which have all SAP services (spool, batch, update, dialog) to avoid a downtime while any of the instances is restarted.