Introduction
What does it take to reduce technical debt, bring faster innovations to on-premise SAP ERP systems?
Frequent Upgrades!
How frequent depends on many factors like usage of the system, priorities of the business, risk appetite, resource availability, timing, etc...
I got the opportunity to be part of a great team to execute a release upgrade of S/4HANA system from 1809 FPS 02 to 2020 FPS 01 recently and I think the lessons learned will be helpful for others.
I want to focus primarily on the Silent Data Migration (introduced from S/4HANA 1909) because it means and works different depending on the type of upgrade. There are many blogs around it but all of them cover the online SDMI, in this blog I want to focus on the SDMI that runs during SUM Downtime.
SAP is investing on improving SDMI like running it during uptime (post upgrade) even for jump upgrades in future releases but not much on existing releases because they don't have the framework and that will be too much effort. So, the goal of this blog to share information that is otherwise have to be practiced to obtain.
Why and Who should care?
If you are (at) a customer running older versions of on-premise S/4HANA 1511 (already out of maintenance support by Dec, 2020), 1610 (end of mainstream support by 2021), 1709, 1809 and considering an upgrade to the latest S/4HANA release like 2020 or 2021, then this is for you.
source: - https://www.sap.com/documents/2020/06/94ca0995-9d7d-0010-87a3-c30de2ffd8ff.html
So, what is stopping you from upgrading to the latest and greatest if you are already considering an upgrade?
I am genuinely curious, please let me know in the comments.
In our case, majority of our technical downtime was spent in SDMI (~8 hrs)
SUM Duration
*This is very specific to our upgrade and will be different for each customer.
If you are curious about the analytical view above, SAP has a cool Technical Downtime Optimization tool that anyone can use for their upgrades.
Even if you don't do a jump upgrade, it is still important to understand the SDMI because that is part of the every upgrade going forward now the Zero Downtime Option is generally available (Yay!).
What is SDMI?
During release upgrade the data structure get changed which warrant a data migration and it typically happens during downtime. So, in order to achieve Zero downtime, SAP solved this problem by moving certain data migrations to happen post upgrade when system is back online. Hence the name Silent Data Migration (SDMI).
There is plenty of information available in SAP blogs and notes, I'm including a few important ones below that are important before an upgrade:
| Topic | KBA |
| SDMI FAQ | https://launchpad.support.sap.com/#/notes/2907976 |
| SDMI Config Options | https://launchpad.support.sap.com/#/notes/2916801 |
| SDMI authorizations | https://launchpad.support.sap.com/#/notes/2850918 |
| SDMI User Management | https://launchpad.support.sap.com/#/notes/2664638 |
| Log Analysis of SDMI during SUM | https://launchpad.support.sap.com/#/notes/2725109 |
What are some different SDMI scenarios?
- Full benefit of Silent Data Migration is realized only if you are doing +1 release upgrade, i.e 1809 to 1909 or 1909 to 2020 or 2020 to 2021, etc..
- If you do a jump upgrade 1809 to 2020 (our case), then the SDMI that needs to run for the release in between (i.e. 1909) will run during SUM downtime.
- Last I heard, SAP is working on making SDMI online (uptime) even for jump upgrades, but only starting from S4HANA 2021 and above (i.e upgrading from S4 2021 to 2023 will run SDMI after upgrade and not during downtime). Take it with a grain of salt, no official documentation yet.
SDMI Scenarios
Important Considerations for downtime SDMI
User Management
The FAQ (Q4 in SDMI note) is vague about the option in SUM tool to allow creating of a technical user for SDMI. It makes it sound like its optional, and even the SUM dialog looks like it (screenshot below).
It is optional only if you are doing next release upgrade (N+1) release.
If you are doing a jump upgrade (N+2 release) especially from 1809 to 2020, this cannot be optional because the SDMI for 1909 release needs to complete during downtime. So you must select the option "Yes" to create the user.
What are the implications?
As covered in SDMI FAQ KBA, this user will be created with SAP_ALL profile. Since this will come up in your SOX audit, it is wise to follow the security process in your company and clear it with approvers before the upgrade starts.
SUM Dialog to create SDMI User
Documentation (or the lack there of)
The data migration is carried out by the execution of SDMI classes, however there is little to no documentation on the implementation of these classes that you can refer before a system upgrade. So in case of an upgrade from 1809 there is no way to know the information prior to upgrade about the SDMI classes, what data is being migrated for what table(s), which are part of downtime and uptime. This is not covered in "whats new" or "help.sap.com"
What are the options?
- you can reach out to SAP, perhaps when more customers request may be SAP can do something about it
- Once you finish the non-production system (preferably a copy of production) examine the SDMI_SUM_PROC<client>.<SID> logs to understand all SDMI class executions during downtime. This is just a list of SDMI classes, no details on what they do.
- If you need more details on each of those classes' purpose, you can reach out to SAP support, but remember you probably have to open an incident per SDMI class product area(refer FAQ KBA).
- Alternately theoretically (I did not try this), you can set a breakpoint at MAIN_NEWBAS/XPRAS_AIMMRG
- Unlock the system via unlocksys command (refer SUM tool guide)
- Goto SDM_MON and double click the class (if its still available) and go to Properties-->Description. That will give one liner on what the class is doing
Downtime Estimation
The lack of information also makes it difficult to estimate the volume of data and consequently the downtime duration. In our case, the SDMI class CL_SDM_SDBIL_VBRP executed during downtime for ~7hrs.
- Just going by the name of class, it seems to be for table VBRP and in our DB the total records are little north of ~450M. However, the logs indicated that only 30% of records needed processing ~140M records.
We eventually found out through our dialogue with SAP support that this class was trying to get rid of joins to VBRK, by copying some fields to VBRP table. So, the volume of VBRK was the correct table to estimate the processing duration. - What is the lesson learned? After doing sandbox, you will have pretty good idea about which classes are running in downtime and which are running longer. There are some actions you can take to improve the performance, but it is inevitable that SDMI will run during downtime. So, if its confusing to estimate the volume of records just by the name of the class, you can try reaching out to the corresponding sap support component to get some answers.
- Also, SDMI needs to run for every client in the system including 000. So if you have multiple productive clients, then be prepared for longer SDMI runs.
Performance tuning
The FAQ and blogs describe in detail about parallelization and the control you can have over SDMI. All of them are applicable only for online SDMI. When you are doing a jump upgrade (N+2 or more) from 1809, the SDMI that needs to run during downtime starts automatically and runs with default configurations. This also means there is no option to fine tune it in any way before the upgrade starts or on the fly.
The only way is to
- set a break point in a previous phase like MAIN_NEWBAS/XPRAS_AIMMRG
- unlock the system using unlocksys command (refer SUM guide)
- Manage parallelization in SDM_MON transaction
Refer part 2 to know more about performance and other issues encountered during downtime SDMI of the upgrade.
Part 2 - https://blogs.sap.com/2021/12/07/s-4hana-upgrade-1809-to-2020-sdmi-lessons-learned-part-2/
Part 3- https://blogs.sap.com/2021/12/07/s-4hana-upgrade-1809-to-2020-sdmi-lessons-learned-part-3/
Regards
Nanda
- SAP Managed Tags:
2 Comments
