Its always good to divide activity in different steps to understand easily. So we will perform Kernel upgrade in below steps. 

Pre-checks

Download

Extraction and update

Check After

 

Pre-checks

Check the current kernel version:

We can check kernel version through different ways. First is at SAP GUI level

As shown below.

1: Login with your credential at SAP GUI level, then got to the System > Status find it.

2: Goto SM51 à SAP Release and record current version details

 

3: Operating system level:

Login at OS level with root use and run command disp+work as show below

 

Software Download

 

Download kernel from Support packages and patches ---> By Alphabetical Index (A-Z) ---> K ---> SAP kernel <bit> <uc> ---> SAP kernel <release> (...) ---> There choose <operating system> ---> both #Database independent and <database specific> archives

EXTRACTION, UPDATE

 

1: Change to profile folder:

2: Find the instance profile

Find DIR_CT_RUN by "sappfpar check pf=<instance pf with full path> DIR_CT_RUN"
Copy kernel folder, in this case NTAMD64 as NTAMD64.bak

Copy SAR files one level above, in this case to "<drive>:\usr\sap\<SID>\SYS\exe\uc":

Stop SAP at this point. Also stop sapstartsrv processes of this SAP system. Refer to Starting and Stopping SAP Systems Based on SAP NetWeaver 

Extract kernel archives by "sapcar -xfj <SAR archive> -R <destination folder>". First extract SAPEXE and SAPEXEDB SAR files and then the rest (dw sar, lib_dbsl sar, etc):

Start SAP start service SAP<SID>_<instance nr> from Windows service manager or by sapcontrol -nr <instance nr> -function StartService <SID> command

1. Restart SAP:
   
2. Restart SAP Start Service:
   

CHECK AFTER

Check the new kernel version:

System > Status:

Operating system level:

 

 Thanks 

what is SAP Buffers and types of Buffer ?

Each SAP instance (application server) has its own buffers. These buffers are also known as client caches because they are implemented on the client, that is, the application server. SAP buffers occupy memory areas that are local to the work process, and in individual shared memory segments that can be accessed by all work processes. These memory areas are executed for the application server.

Some of the shared memory segments in an SAP System are grouped into one shared memory segment known as a pool. This is done to meet the operating system limits on the number of shared memory allocations per process. In most operating systems, you can allocate as many shared memory segments as required. The limits depend on the kernel configuration. The AIX operating system, for example, allows 10 shared memory segments per process.

SAP buffers store frequently-used data, and make this data available to the local application server instance. This helps to reduce the number of database accesses, the load on the database server (it does not need to be accessed repeatedly to obtain the same information), and network traffic. As a result, system performance is considerably improved.

The data that is buffered includes ABAP programs and screens, ABAP Dictionary data, and company-specific data. Typically these remain unchanged during system operation.

You can change, or tune, the sizes of buffers to optimize performance for a particular hardware configuration. There are several ways to tune buffers. As there are many constraints to consider when change the buffer size, several difficulties may arise.

You can use table buffering to fine-tune applications, that is, some or all of the contents of infrequently changed tables can be held in local buffers.

SAP Buffers

Program Buffer : This buffer occupies a whole shared memory segment.

Screen Buffer: These buffers are held in a shared memory pool. All work processes can access this pool.

Roll Area: Local work process buffers. Only one work process can access these buffers at a time.

Thanks

What is SAP Message server, its use and administration of it ?

The SAP message server runs as a separate process, mostly on the same host as the central instance. If an SCS instance (SAP Central Services) or ASCS instance (ABAP SCS) is configured in the system, the message server is part of this instance.

Only one message server can run in each SAP system. 

USE

It performs the following tasks in the SAP system:

• Central communication channel between the individual application servers (instances) of the system
• Load distribution of logons using SAP GUI and RFC with logon groups
• Information point for the Web Dispatcher and the application servers (each application server of the system firsts logs on to the message server)

When an instance is started, the dispatcher process contacts the message server so that it can announce the services it provides (DIA, BTC, SPO, UPD, and so on). If the connection setup to the message server fails, an entry is made in the system log (syslog).

If the message server stops working, it must be restarted as quickly as possible to ensure that the system continues to operate smoothly.

Monitoring 

We have different options for monitoring and testing the message server:

Monitor the Message Server in the SAP System

To monitor the message server, We can use the message server monitor (transaction SMMS) in the SAP system. We can check and change all the important settings, create and view trace files, read statistics, and so on.

Monitor the Message Server from the Browser

We can display details of the servers and logon groups from the Web browser too. To do this, use the host of the message server and the HTTP port of the message server ( ms/server_port <xx> profile parameter) in the URL.

Monitoring and Testing the Message Server at Operating System Level

At operating system level there are various programs available that are delivered with the standard system.

We can normally find the test programs in the /usr/sap/ <SID>/SYS/exe/run executable directory.

The msmon monitoring program provides the same functions as transaction SMMS in the SAP system.

We can use the lgtst test program to check the connection to the message server and to display the active instances and logon groups that the message server can currently see.

We can use the msprot program to monitor the message server. The program continuously issues the status of the application servers logged on the message server and is stopped if the message server is stopped. We will be notified of the termination of the message server and can respond to this.

Thanks 

What is Soft Shutdown in Application Server ABAP #SAP Basis Administration

 Shutdown

 The application server is in the shutdown phase, that is, it will be terminated. This state is similar to the passive state, but cannot be changed to the active state. This state or phase ends with the termination of the server.

      Soft Shutdown : To ensure that no requests or data are lost when closing an application server instance (AS instance), we use the soft shutdown function. A soft shutdown waits for transactions to be completed in a specific order. In this order, some states have a timeout, which can be configured with profile parameters. Other states have no timeout. Therefore, it cannot be guaranteed that the soft shutdown will terminate within a certain time span (sum of all timeouts).

We trigger the soft shutdown in transaction SM51. At the start the AS instance has status Active.

The following overview describes soft shutdown process and the actions of the system in the various states.

  

What are the different states of the SAP Application Server ?

 Its important the the different states of the SAP Application server and following application server states.

Initial: 

 The application server has logged on to the message server. When the server is in this state, it cannot be accessed.

Started

 The application server starts the work process and initializes all required services. Requests cannot be processed in this phase.

Active

 This is the “normal” state of the application server. It receives and processes requests, and creates and sends requests to other servers.

Passive

  The purpose of this state is to “logically” remove from the system a server that has to be stopped during productive operation. The server still processes existing requests, but does not get any new ones. It can then be shut down without any relevant requests such as requests or batch jobs having to be canceled.

The state can be changed to the active state.

Shutdown

 The application server is in the shutdown phase, that is, it will be terminated. This state is similar to the passive state, but cannot be changed to the active state. This state or phase ends with the termination of the server.

      Soft Shutdown : 

To ensure that no requests or data are lost when closing an application server instance (AS instance), we use the soft shutdown function. A soft shutdown waits for transactions to be completed in a specific order. In this order, some states have a timeout, which can be configured with profile parameters. Other states have no timeout. Therefore, it cannot be guaranteed that the soft shutdown will terminate within a certain time span (sum of all timeouts).

We trigger the soft shutdown in transaction SM51. At the start the AS instance has status Active.

Stop

  The application server has terminated the connection to the message server and can no longer be accessed.

  

Configuration of the Process Overview (Transaction SM50)

Depending on the configuration of the process overview (SM50) some of the functions described in this documentation may not be displayed. In the menu List  Configuration you can customize the process overview (SM50) to your working requirements and show or hide certain functions and information.

Configuration of the Process Overview

The most important administration tasks are listed for reference below:

Managing Work Processes

1. Terminate ABAP Program
2. Debug ABAP Program
3. Display Active Processes
4. Display Details of a User
5. Display Details of a Process
6. Delete Session
7. Terminate Process (With or Without Core)
8. Restart Processes if There Is a Bottleneck - Configure Dynamic Work Processes
9. Start Process After Error/Termination Automatically
10. Cancel Request Processing
11. Display System-Wide Process List
12. Reset Terminations
13. Reset the Info Area

How to start, stop and manage the ICM service in SAP system ?

 The following functions for starting, stopping, and managing the ICM are available from the administration menu in the ICM monitor (transaction SMICM):

Exiting the ICM

Choose Administration   ICM   Exit Soft or Hard Exit to soft-terminate (signal 2) or hard-terminate (signal 9) the ICM. With a soft termination, the ICM still tries to send responses to its existing clients, but does not accept any new connections. With a hard termination, the process is simply terminated at operating system level. All existing connections and, of course, all requests are lost.

Maintenance Mode

If the ICM has the status running, We can put in into maintenance mode. Choose Administration   ICM   Maintenance Mode   Activate. We can leave the maintenance mode in the same menu by choosing (Deactivate). The ICM will then have the normal running status again.

Reload Configuration.

While the ICM is running We can get it to reload configuration data that can otherwise only be updated periodically or when the ICM is started. Choose Administration   ICM   Configuration  Reload.

Reloading configuration data means:

Invalidates the host name buffer; more information: Host name buffer

Invalidates the server cache.

Updates information from the message server and application servers (Web dispatcher only).

Exits from the maintenance mode if this was active.

Reloads filter rules; more information: Template, section: Initialization of the Content Filter

Setting Start Options

Choose Administration-> ICM--> Start Options --> Set, to set the trace file and the trace level of the ICM. Standard is dev_icm and 1.

Restart

If the ICM is terminated (due to an error or by the administrator), it is automatically restarted by the dispatcher. We can control this behavior by choosing Administration  ICM Local   Restart  Yes or No. If We deactivate the restart and exit the ICM, it will not be restarted.

Administration of the AS Java

The functions under Administration  J2EE Instance (local) / J2EE Cluster (global) are used to manage AS Java (JEE Engine). The functions are described in Administration of the AS Java.

How to monitor the status of the ICM ? ( SAP Basis Administrator)

 We can use the ICM monitor (transaction SMICM), which provides various functions for monitoring the status and configuration of the ICM and for detecting any possible errors.

We can find the functions described here in the Goto menu.

Trace Files

Using Goto -- Trace File or Goto -- Trace Level, We can display the trace file dev_icm, reset it, or set the trace level (values between 0 and 3 are possible, default is 1). We can also display just the start or the end of the file (the first or last 1000 lines). This is a very useful function for large files. Choose Goto  Trace File   Display Start or Display End.

We can download the trace file on to Wer local computer, which is very useful for large files or if We want to store a file or reuse it later. To do this choose Goto  Trace File  Save File Locally.

Security Log

To view the security log, choose Goto --> Trace File --> Security Log --> Display. We can also download the security log and display general information about it.

dev_icmbnd

If We want to view the trace file of the external binding program icmbnd, choose Goto -->Trace File--> Display--> Dev_icmbnd

Parameter

To display or change ICM profile parameters, choose Goto -->Parameters. If We choose Change, for each listed parameter We can display the RZ11 documentation, by placing the cursor on the parameter name, and choosing Documentation Documentation.

The value field is ready for input for those parameters that can be changed dynamically.

Statistics

Choose Goto > Statistics to activate, deactivate, display, and reset the ICM statistics.

Memory Pipes

Choose Goto> Memory Pipes for information on the memory pipes that are used for data exchange between the ICM and the work process.

Host Name Buffer

The mapping of host names to IP addresses or of service names to port numbers is buffered in the SAP system, once they have been read from the file system. If a host name or a service name that should be accessed is changed, the host name buffer must be reset. We can display the buffer contents and reset the buffer. Then the ICM reads the updated data from the file system.

To do this choose Goto> Host Name> Buffer>  Display or Reset.

Services

Choose Goto > Services to monitor and administer the services (ports that are used for the ICM connections).

Release Information

Choose Goto > Release notes  to display information about the version of the ICM, the release and the patch level of the SAP kernel.

The first line contains general information on the ICM.

kernel information tells We the release of the SAP kernel. Besides kernel release and compile information, this screen provides the following information:

update level specifies with which kernel releases the kernel can run in an SAP system. If different application servers should run in a system with different kernel patch statuses, they must all have the same update level.

patch number specifies the last patch level that is relevant for the component ICM.

source id (the numbers after the point) indicates the actual kernel patch level.

Important Tcode of the SAP ABAP System Monitoring ( SAP Basis)

 There are multiple things in SAP Application those help us to get current status of SAP system. As a SAP basis administrator we need to ensure everything running fine before business start. 

For same below are the few things we need to check during daily monitoring of system. 

1) OS level monitoring

 a) file system monitoring

 b) Network connections: SAP Router

2) SAP System monitoring

  a) Check DB and SAP services

 b) Working with tcodes to monitor SAP system

Working with tcodes to monitor SAP system:

SM51 List of SAP Systems

- Display list of active/up/running application servers that have registered 

- Also you can also manage, and display the status of the users (SM04), Gateway (SMGW), ICM (SMICM), SNC, Release notes, Remote logon, System log entry (SM21) and browse SAP directories from "Goto" option

- Also you can check what WP's are defined for every listed Instances from the "message type" field  ex, DIA,BG,UP,SPOO etc., Note:: From release 7.1 no "Enqueue WP" will not display to monitor use ensmon tool.

- If you are logged on DI1 and want to check something on DI2 then select the system DI2 from SM51 - double click and enter the tcode

SM50 Work Process Overview

Monitor this section and look that enough WPs are in waiting status to hanlde next user request

Display list of WPs (DVEBMGS) - look for Status and Action tab

You can read dev_wp* file directly from here without going to OS which is present at /usr/sap/SID/DVEBMGS00/work/*

To display the file clieck on "Display file" Icon or ctrl+shift+f8 will open the file

Also we can cancel any active process from Process menu with core generate file or wihout core will not generate log file

SM66 Systemwide Work Process Overview

Global workprocess is very usefull when we have more than 1 DI this will show all WP (CI,DI) WP status

look for all WP processes and observe error (red) or in stale state,

We can also display only stop process goto => process list => select process => check status

Restart the stop process by going to stop wp app server (sm50) => select wp => process => Restart after error => yes

SM12 Display and Delete Locks

At selection only give client no and execute look for old entries sorting by time, It may possible to observe 6-7 days old logs or more but before taking any action look in details for user status and get details from AL08/SM04 for current action, more you can check if any Background job is running with that user name from (SM37) check if any jobs are active for that user if nothing is happening check for any stale connection from SM04/AL08 and disconnect the user from SM04 then check if the lock is clean if not then delete this manually

To get details select lock and click on "Details" (F2) screen will popup look for:

User,Sysno,WP,tcode to analyse further by check wp trace file and system log (SM21)

Get details on lockmode (click F1) and Cumulative Counter

SM13 Administrate Update Records

Check the update system which has to be "Update is active" select status all and execute

Select if any "Error" status click on "Update Header" (hat icon) look for Error details,User,Tcode,Update server to analyse further also double click on error details it will give more details Ex, ABAP dump etc.,

AL08 Users Logged On

Check no of logged users for all instances (CI,DI)

SM04 User List / AL08 - Global user over for multiple Instance

Find stale user connection before taking any action check if there's no job,program or nothing is running by selecting the user - select sessions

Sometime you w'll see users without any sessions in this case look for "Type" this will be a : RFC, Plugin Http etc.,

SM37 Overview of job selection

Analyse: cancelled jobs

Select canceled job and clieck display job log => The log contains every step details which is completed and cacelled look for the one which is canceled => look if this is due to some functional issue, ABAP Dumps, program dependent, variants etc.,

To get more details double click on the job => go to job details => look for target server and wp to analyse further or select job go to edit => choose details => to view client,system,timings etc.,

To search jobs by program name Ex- RSPO1043 to find the job name

We can also view the spools generated by job, modify steps, program, variants, schedule timings etc.,

To analyse the long running jobs select the job => goto => job statistics => analyse by - res time, db req time, wait time, transfer data double click to analyse more

Also look for standard SAP jobs (start with SAP*) were running sucessfully if not then need to do start or if failed then analyse : SAP_REORG_JOBS, SAP_REORG_SPOOL, SAP_REORG_BATCHINPUT, SAP_REORG_ABAPDUMPS, SAP_COLLECTOR_FOR_JOBSTATISTIC,

SAP_COLLECTOR_FOR_PERFMONITOR etc.,

ST02 Setups/Tune Buffers

World of SAP buffers...

Look closely for every parameter specially those which is displayed in red so wherever the red alert is there change the parameter value depends on requirement but before that analyse and display the current value by double click => current parameters => to see all parameter for all area select all or on main screen current parameters

Keep in mind that each buffer holds different values

If you want to get your hands more sirty on this then go to => detail analysis menu => look every values under SAP runtime buffers and to see DB hot ration and quality for the week goto main screen => summary of all buffers (shift+f2) scroll down untill you see "Development of SAP buffers"

Use below command for swap space requirement for SAP application server:

sappfpar check pf=/usr/sap/<SID>/SYS/profile/<Inst_Prof> nr=<Sys No> name=<Systemname> | more

ST06 Operating System Monitor

look for user utilization, Disk res. time, swap info etc., double click on utilization user to get hourly details on CPU utilization

Go to "Detail Analysis" to get HW Info, OS logs, Memory, Filesystem, LAN etc.,

If this reports to high CPU utilization check for the highest utilization process in Unix / Linux by "TOP" select the PID and do the analysis from "SM50" also check SM66 / SM66 CPU filed by clicking on white watch icon and find the highest utilizing CPU, check under SM37 by secting only active process sometime may be of jobs execution also bring high utilization

ST04 DB Performance Monitor

Take a look at Buffer Quality and Hit Ratio a healthy system always point to 98.xx

Analysing poorest SQL queries goto => sql cache => delete filters => take a look of total execution column

monitor DB growth, Tablespaces,Missing Index etc.,

ST22 ABAP dump analysis

The theory of analysing the dumps are not depend only with ST22 sometime you may also need to work with => SM21,SM50,SM37,STAD,ST03N,ST02,RZ10 etc, and finally searching in SAPNotes for proper understanding to solve it.

Quick Look-up Fields => User and T-code, What happened, Error Analysis etc.,

ST03 Workload and Performance Statistics

Monitor Response time for Transacton : Select app server under expert mode => select duration, date-time, day etc., => Select transaction profile => standard => check for poorest t.response time filed and observe if this t-code is coming every time in poor response

Response time from user => Expert mode => user and settlement => user profile => look for t.response time from the filed

Also use STAD to collect more data by user, tcode, program with with multiple instance selection and more

DB02 Tables and Indexes Monitor also called as Static Database Monitor (DB02_MSS - MS.SQL)

Monitor DB size, Tablespaces size, Tables and Indexes (also find missing indexes here)

List of default tablespaces:PSAPTEMP, PSAPUNDO, PSAP[SID], PSAP[SID]620, PSAP[SID]UDR and SYSTEM

A Refresh button is provided to update the information.

DB analysis: Offers a number of options to execute checks on the database

Detail Analysis : Executes a consistency check for a specified table and returns detailed information about the table.

 

Analyse Missing Indexes:

Choose the Database analysis button => A list of available database checks is displayed => To start the search for missing indexes, choose DB <-> ABAP/4 Dict. In the dialog box that appears choose Recheck => When the check has finished, the results are displayed on the screen.

DB12 DBA Backup Logs

Monitor: DB and Archive Backup logs

Check for logs on failed backup, duration of complete backup, size of last backup Database, backup device type information etc.,

DB14 Display DBA Operation Logs (Oracle)

Logs generated during execution of BRSPACE, BRCONNECT, BRARCHIVE, or BRBACKUP

SARFC Server Resources for Asynchr. RFC

Monitor available Server Resources for Asynchr. RFC in R3 system (Ex-R3 connected with BW)

SMQS Registration of Destinations

qRFC Monitor - check scheduler information and status

SMQR Registration of Inbound Queues

SM59 RFC Destinations (Display/Maintain)

Create, Change, Delete, Test RFC's using ABAP connection R3 to R3 or R3 to BW, APO, GTS etc, use TCP to use ex

Check RFC connections perform connection test and authorization test

To check RFC is working Select RFC => Utilities Test => Connection Test or Authorization Test.

SM21 Online System Log Analysis

System logs analysis for local or all instances analyse logs by user, tcode, date and time, WP select problems only and execute all red text display are problems like Dumps, connection errors, Os, DB etc.,look specially for resource related entries

To get logs from all instance goto => system log => choose => select all remote system logs => execute

SM28 Installation Check

Perform this check after restart, kernel, patch, notes, add-ons upgrade or any other critical activity

SMLG

Create, change, delete logon groups

Check for all define logon groups are in green status

To create goto create assignment => logon group name ex: INDIA, provide Instance name =>

Assignment Specific  : properties specific to this 'group-server' pair.

IP address  : Frontend IP connection

Group Specific   : properties specific to this logon group.

External RFC enabled : If external RFC logon is allowed or not.

Application Server Specific - properties specific to this application server.

Response Time  : Threshold of the average dialog response time

User   : Threshold of the number of logon users

SMICM ICM Monitor

Check status of ICM and Active Services: goto => services => HTTP / SMTP with their port nos pointing to right app server

Check for parameter and trace file for error log

For dual stack manage the J2EE Engine from here goto administration => J2EE Instance => Sending a Soft / Hard Shutdown, end process, restart

SOST - SAPconnect Send Requests

View the logs sent by SMTP,FAX etc.,

Look for error details on "No Delivery" and current waiting status

Also execute or repeat send for all and selected requests

what are the different Maintenance phases in SAP Release ?

SAP provides mainstream maintenance (formerly: standard maintenance) as part of the maintenance strategy. At the end of the mainstream maintenance period for a release of an SAP application, the following scenarios are possible

Mainstream Maintenance 

Mainstream maintenance is offered for all SAP software products and begins with the Release-To-Customer (RTC) milestone and continues throughout the unrestricted delivery phase. Usually, the end of mainstream maintenance for an SAP software product is later than (or equal to) the end of mainstream maintenance of the predecessor product and after General Availability (GA) of a successor product. 

During this period, SAP provides: 

Security patches and vulnerability fixes  

Bug fixes and software corrections (SAP Notes)  

Legal and tax updates (country-specific changes)  

Compatibility updates for supported databases, operating systems, and browsers  

Performance improvements  

New support packages and feature package stacks (where applicable)  

Full SAP incident support through SAP Support  

Knowledge Base Articles (KBAs) and documentation updates 

Mainstream maintenance is offered for all SAP software releases. Mainstream maintenance begins with the release-to-customer date and continues throughout the unrestricted shipment phase. During the mainstream maintenance phase, you receive support according to your support agreement with SAP. Towards the end of mainstream maintenance, you have three options: 

1: Upgrade - Typically SAP recommends to upgrade before you reach the end of the mainstream maintenance phase. The delivery of new releases of the licensed software (if available), as well as upgrade tools, are covered by the SAP support contract. Go to the Upgrade Information page to learn more about the possible transition options and SAP's offerings to efficiently support the upgrade. 

2: Extended Maintenance (see below) 

3: Customer-Specific Maintenance (see below) 

Extended Maintenance 

Extended maintenance is available for SAP Business Suite 7. The scope of support for the extended maintenance period is similar to the scope of support provided during mainstream maintenance. Extended maintenance requires an additional payment and specific maintenance addendum based on a valid maintenance contract. For further details, see the product specific maintenance information section. 

Customer-Specific 

Maintenance Customer-specific maintenance is generally offered for all SAP products except for SAP Business One. For SAP BusinessObjects solutions different rules apply, please refer to SAP Note 3348644 for more information. Products can enter the customer-specific maintenance phase in one of following three ways: • Customer’s extended maintenance contract term ends • Mainstream maintenance period ends, and extended maintenance is not offered • Mainstream maintenance period ends, and extended maintenance is offered, but the customer does not choose to take advantage of the offer A product enters customer-specific maintenance automatically and there is no need to apply for an additional contract. During customer-specific maintenance, SAP offers support services like those offered in the mainstream maintenance phase, with some restrictions, including: • No delivery of new support packages • No updates to cover legal changes • Technology updates are limited • Problem resolution is customer specific, which means customers are charged for solving problems not yet known to SAP Customer-specific maintenance currently does not have an expiry date. The scope of Customer‑Specific Maintenance is strictly defined in SAP Note 52505. This document does not expand, modify, or interpret the commitments defined in SAP Notes. In case of discrepancies, the SAP Note text prevails. 

Note the following restriction:

SAP cannot support software from third-party providers (for example, operating systems, databases or components), which is no longer maintained by the manufacturer. Therefore, you may have to carry out an upgrade to more current versions of this software. However, more recent versions of the software may not be supported for releases in customer-specific maintenance. In this case, it is your responsibility to decide whether you want to carry out an upgrade or continue using the old version of the software that is no longer supported.

During customer-specific maintenance in particular, you may experience problems if your system has an obsolete Support Package level. You may encounter problems that have been corrected with a more recent Support Package. In addition, it may be more difficult or even impossible to create individual corrections.

 

Support after end of mainstream maintenance or extended maintenance # 52505

 

SAP provides mainstream maintenance (formerly: standard maintenance) as part of the maintenance strategy. At the end of the mainstream maintenance period for a release of an SAP application, the following scenarios are possible:

• After mainstream maintenance has ended, SAP provides extended maintenance for an additional maintenance fee. Extended maintenance has a similar scope of service as mainstream maintenance.

• The customer accepts the offer and concludes a supplementary agreement for extended maintenance (for extended maintenance of SAP Business Suite 7, see SAP Note 2881788). After the validity period of the supplementary agreement has expired, the release automatically enters customer-specific maintenance.

• The customer does not accept the offer of extended maintenance. After mainstream maintenance has expired, the release automatically enters customer-specific maintenance.

• SAP does not provide extended maintenance after mainstream maintenance has expired. After the end of mainstream maintenance, the release automatically moves to customer-specific maintenance (for some applications in the portfolio of SAP BusinessObjects, different rules apply; for more information, refer to the white paper "SAP's Release Strategy" at https://support.sap.com/releasestrategy).

The dates for the end of mainstream maintenance (and extended maintenance, if provided) are published on the SAP customer support website at https://support.sap.com/releasestrategy and in the Product Availability Matrix at https://support.sap.com/pam.

Note that individual, downward-compatible software components within a release of an SAP application (for example, SAP GUI or SAP Kernel) can have a shorter maintenance period and must be exchanged with a newer version during the mainstream or extended maintenance of the release.

Scope of service of the customer-specific maintenance
As of a certain time in the life cycle of a release, it is no longer adjusted to external requirements. Such requirements are, for example, the need to implement legal changes or support new technologies. The time in question is marked by the end of the extended maintenance or the end of the mainstream maintenance if no extended maintenance is provided. As of this time, the customer-specific maintenance begins.

Customer-specific maintenance applies to all SAP applications with the exception of some applications in the SAP BusinessObjects Portfolio and does not have an expiry date. More information about special maintenance strategy rules for SAP BusinessObjects is available in the white paper "SAP's Release Strategy" at https://support.sap.com/releasestrategy.

During customer-specific maintenance, you must pay the maintenance fee in accordance with your maintenance contract (for example, SAP Enterprise Support or SAP Standard Support). The customer-specific maintenance does not have to be ordered explicitly.
In customer-specific maintenance, customers receive similar maintenance services in accordance with their maintenance contract (as far as these services were delivered during mainstream maintenance for the relevant release), however, there are some restrictions in the scope of service because the release is no longer adjusted to new requirements, as described above.

During customer-specific maintenance, the following restrictions in the scope of service apply:

• No delivery of legal changes

• No delivery of Support Packages

• No guarantee for technological updates, for example:

• No new kernel versions for the support of new database versions and operating system versions

• No new patches for non-ABAP components (for example, Java patches or front-end patches)

• In some cases no direct upgrade to a current release. In this case, the upgrade to a current release must be performed in several steps.
  For a start release in customer-specific maintenance, we do not usually provide new or additional upgrade paths. Upgrade paths that are provided during the mainstream maintenance or during the period in which we provide extended maintenance continue to be available during customer-specific maintenance. You can use available upgrade paths whether or not you make use of the extended maintenance.

• No support of new interfaces

• Processing of problems is customer-specific. This means that for known problems, the solution of problems is still covered by the maintenance. However, the customer may have to pay for the expense of solving new problems not yet known to SAP. This applies to customer-specific enhancements in particular.

• The service level agreements for initial response times and corrective measures are no longer delivered.

• Remote support for support during the evaluation of the latest Enhancement Package is no longer provided for Enhancement Packages that are based on releases in customer-specific maintenance.

Note the following restriction:

• SAP cannot support software from third-party providers (for example, operating systems, databases or components), which is no longer maintained by the manufacturer. Therefore, you may have to carry out an upgrade to more current versions of this software. However, more recent versions of the software may not be supported for releases in customer-specific maintenance. In this case, it is your responsibility to decide whether you want to carry out an upgrade or continue using the old version of the software that is no longer supported.

• During customer-specific maintenance in particular, you may experience problems if your system has an obsolete Support Package level. You may encounter problems that have been corrected with a more recent Support Package. In addition, it may be more difficult or even impossible to create individual corrections.

Detailed information about customer-specific problem processing:
For releases in the customer-specific maintenance, problems are processed according to the following rules:

• Customers can continue to create messages as usual. The normal service and support tools (for example, the SAP customer support website and SAP application lifecycle management) and the SAP Customer Interaction Center/Support Advisory Center continue to be available.

• Primary Support and downstream institutions accept and process problem messages during the regular message processing. This includes, among others, the 7x24h Support for messages with priority "Very High" (for more information about the priority of messages, see SAP Note 67739).

• The reported error is analyzed.

• If the software error is already known, an SAP Note that has been released for customers and that documents the problem exists for the relevant release. An already known solution is made available to the customer.

• If the error is not known yet, no SAP Note documenting the problem has been released for customers for the relevant release. The error is regarded as a new, as yet unknown error. In this case, further processing is regarded as a consulting service subject to charge.

• There are several options to correct the error:

• Standard correction using an SAP Note: The error is documented in an SAP Note, which is then available to all SAP customers. The relevant SAP Note contains the corrections for the error.

• Standard advance correction (see SAP Note 538778 also): The error is documented in an SAP Note, which is then available to a restricted number of installations. The relevant SAP Note contains the corrections for the error.

• Customer-specific corrections: The error is documented in the problem message for this installation. The corrections for the error are documented in the problem message.

           SAP specifies the form in which corrections are provided to the customer.

• SAP cannot guarantee that every problem can or will be solved within customer-specific maintenance. For example, SAP cannot provide corrections in cases such as those specified below:

• Problems that are caused by third-party software; especially if the software is no longer supported by the third party

• Problems that are caused by software components whose source code is not available to the customer

                    One of the reasons for restrictions is that SAP removes the internal system landscapes for a release at the start of the customer-specific maintenance of that release. As a result, it may only be possible to analyze the error directly in the customer system. For the analysis, the customer has to make a remote access available.
                    It may only be possible to correct as yet unknown errors as individual corrections in the customer system. In the customer system, SAP acts as a developer of the customer and has no further rights. Therefore, SAP cannot provide corrections for software components whose source code is not available to the customer. SAP cannot provide corrections for as yet unknown errors with third-party products that are no longer supported by the manufacturer.

• You can find more information concerning message processing and the cost of message prosessing subject to charge in the country-specific consulting notes under XX-RC and XX-SER-GEN.

Detailed information about individual support services

Support Packages, Support Package Stacks and kernel patches
The archive of the Software Download Center contains Support Packages that are available during mainstream maintenance for releases that are already in customer-specific maintenance (we use SAPR/3 4.6B as an example here):
https://support.sap.com/swdc
-> Download
-> Support Packages and Patches
-> Archive for Support Packages and Patches
-> My Company's Application Components
-> My Company's Software
-> SAP R/3
-> SAP R/3 4.6B

When a release is in customer-specific maintenance, the Support Package Stacks that were available during mainstream maintenance are no longer visible in the Software Download Center. You can still access Support Packages using the Software Download Center archive.

The following path contains old kernel patches for kernel versions no longer in maintenance:
-> Support Packages and Patches
-> Archive for Support Packages and Patches
-> My Company's Application Components
-> Complimentary Software
-> SAP Kernel

The following path contains kernel patches for kernel versions in maintenance:
https://support.sap.com/swdc
-> Download
-> Support Packages and Patches
-> My Company's Application Components
-> Complimentary Software
-> SAP Kernel

Installations and upgrades
We do not support installations or upgrades to target releases that are in customer-specific maintenance. If you require the installation software, for example, when you migrate a database or an operating system, create an SAP customer message under the component XX-SER-SWFL-SHIP. Depending on the release, the provision of the installation software may require some processing time.

Information Sources: PAM and Support Package schedules:
Information about the maintenance duration and maintenance phases for SAP software releases can be found in the Product Availability Matrix (PAM) on the SAP customer support website at https://support.sap.com/pam.

For information about the availability of Support Packages, go to https://support.sap.com/hrsp (for SAP HR Support Packages) and https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/schedules-for-maintenance-deliveries.html (for Support Packages for other software components).

Product documentation
SAP recommends that customers archive the relevant product documentation and other types of user assistance locally. Customers must have available the relevant hardware and software that is required to display the user assistance.

Additional information about maintenance is available on SAP Support Portal at https://support.sap.com/maintenance.
For more detailed information, contact your Account Team.

 

HANA Database Upgrade: How to Choose the Right Target Version

When planning a HANA database upgrade, it’s important to evaluate a few key technical checkpoints before moving forward. This includes validating SAP application compatibility with the target database version, understanding the supported N-1 version strategy provided by SAP SE, and confirming whether a direct upgrade path is available from the current HANA version to the desired target version. Reviewing these factors early helps minimize upgrade risks, prevents compatibility issues, and ensures a smoother execution. In this blog, we’ll walk through these considerations in a practical way to help you plan your upgrade with confidence.

Please refer SAP Note “1948334 - SAP HANA Database Update Paths for SAP HANA Maintenance Revisions” which provide use details about SAP HANA maintenance revisions specifying in detail the supported and unsupported update paths (Lists of SAP HANA Revisions (HANA 1.0 and HANA 2.0) specifying in detail the supported and unsupported update paths). For all update paths not explicitly listed in note, only regular update procedure applies! The regular update procedure is upgrading from a lower revision to a higher revision.

 * Please Note that SPS05 which is used as intermediate jump will be out of maintenance in 31.12.2025

Note:

• If you upgrade from a SAP HANA 1 revision prior to revision 69.07, first upgrade your system to SAP HANA revision 69.07 before upgrading to the target revision.
• The HANA 1 revision numbers 75 through 79, 86 through 89, 98 through 99 and 103 through 109 have been skipped.

Upgrading a HANA 1 system to HANA 2:

1) Please read the guideline for upgrading a HANA 1 system to HANA 2 in SAP Note 2372809.

2) In an MDC landscape, the systemserver doesn’t have separated metadata space if the binary version is earlier than the maintenance revision 122.04.
    If you start your upgrade to HANA 2.0 from a SAP HANA 1system in a multiple-container mode (MDC), you first upgrade the latest SAP HANA 1 Support Package Stack (SPS) 12 maintenance  revision. Please take care of the unsupported upgrade paths (tables above).

3) Please check the supported Operating Systems of both source and target revisions using 2235581 before upgrading. 

For more information about the SAP HANA revision and maintenance strategy, see SAP Notes
2021789 - SAP HANA 1.0 Revision and Maintenance Strategy
2378962 - SAP HANA 2.0 Revision and Maintenance Strategy