Introduction
If you are a person who likes to watch multi part movies in the sequence they were released, then I highly recommend reading Part 1 and Part 2 first to get an understanding on SDMI scenarios.
We recently upgraded from S/4HANA 1809 FPS 02 to 2020 FPS01 and I will share the issues we encountered in online SDMI post the upgrade. The issues covered are applicable to all upgrades (not just jump upgrades like previous two parts).
This SDMI is very important, because if these are not completed successfully, these will be flagged as warning/error in the SI checklist run for the next upgrade.
Background
Right after the upgrade when you go live, the batch jobs are released. When btctrns2 is executed the standard SDMI job SAP_SDM_EXECUTOR_ONLINE_MIGR in SJOBREPO will start and start the execution pending SDMI classes.
In short when you release batch jobs when you go live, it will start the SDMI for pending classes post upgrade.
So, it is very important to configure the Max Parallel processes in SDM_MON before you release the jobs. If you had 100% parallelization, then all DIA work process will be occupied.
CL_SDM_FARR_D_CONTRACT_VERS_CD
This is relevant for companies that have SAP RAR (Revenue Accounting and Reporting) enabled in their system.
In S/4HANA 2020, table FARR_D_CONTRACT has a new field, RAR_VERSION_CODE on contract level indicates whether the contract has been created in a "Revenue Accounting Classic" or in the new "Revenue Accounting" environment
This data migration is executed by the SDMI class CL_SDM_FARR_D_CONTRACT_VERS_CD.
This data migration class caused lock overflow consuming more than 200k locks and impacting the system. The only good news is it was very short, but still caused batch job aborts and inbound idoc issues.
SM12 - Lock overflow caused by CL_SDM_FARR_D_CONTRACT_VERS_CD
This is possibly because of parallel sessions trying to acquire locks. In SLG1, the logs indicate that the class tried to acquire even more locks and failed
SLG1 - CL_SDM_FARR_D_CONTRACT_VERS_CD failing to acquire locks
Sadly, we did not get to explore this further because of production dependencies and we just restarted it to completion. Unfortunately this slipped our radar in QA as well.
If you encounter this, I highly recommend setting parallel processes to just 1 and try to see if the lock overflow doesn't happen.
We have given feedback to SAP and they were looking into it the last I heard.
CL_FINS_SDM_ACDOCA_NETDT
In S/4HANA 2020 the SDMI class CL_FINS_SDM_ACDOCA_NETDT moves field NETDT from BSEG to ACDOCA. In our system we north of 4B records with 21 partitions.
This SDMI class started and failed soon and kept failing with minimal to no records processed.
SDM_MON - CL_FINS_SDM_ACDOCA_NETDT History
SLG1:
... Begin of Migration ...
NETDT AMDP Exception: A database error occured. The error message in the database was: "transaction rolled back by an internal e
NETDT migration: Exception occured when selecting view Z00166V000010012
As per SAP HANA DB -PERF team, the root cause had to do with update handling of partitioned data.
SAP suggested to use the new update engine to avoid the error by setting the multistore_feature_toggle parameter via:
ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'system') SET ('sql', 'multistore_feature_toggle') =
'(multistore_operator, column, update, true)' WITH RECONFIGURE;
The solution worked and processed about 7M records before failing at a different part, same old PFW (parallelization framework).
SLG1:
Persistence Service: table ACDOCA already processed by PFW:00168:PFW_MAIN++:00010:10
Enqueue on CL_FINS_SDM_ACDOCA_NETDT failed (FOREIGN LOCK) - a Migration is already in progress
Split of DB object Z00221V000010024[0] results no packages
Dispatcher adviced to Cancel processing due to error exception raised
The good folks at BC-DB-HDB-PFW explained that the exception is a precaution to avoid erroneous table properties of table ACDOCA (auto merge and auto optimized compression concretely).
An old PFW instance 168 edited the table properties and probably crashed. Due to the crash it has not been able to switch back the table properties to the original state.
Now another instance tries to run on the same update table ACDOCA, which is prevented.
They were not able to figure out why the instance crashed in the first because it was too long ago (yes the incident took 4 months to resolve). My guess is that when the class failed initially due to DB errors it caused the crash.
The solution was to run the report SHDB_PFW_CRASH_CLEANER without any parameters.
The SDMI class was restarted and completed successfully. About 4B records processed in ~30hours with just 4 parallel processes
SDM_MON - CL_FINS_SDM_ACDOCA_NETDT Completion
The HANA-DB-PERF team reported that the update handling will be permanently fixed in
- SAP HANA 2.0 SPS05 - Rev 2.00.059.00 Released on 19Nov2021
- SAP HANA 2.0 SPS06 - Rev 2.00.060.00 Planned release on Dec 2021
So if you are planning an upgrade to S/4HANA 2020, it is recommended to upgrade to either of these DB version, so you can avoid the SDMI failure for class CL_FINS_SDM_ACDOCA_NETDT.
CL_SDM_BALHDR_ALSTATE
This SDMI class fails due to a know error outlined in KBA 3019742.
SLG1 log:
Set the status to CANCELLED due to no progress
Records to be processed at first migration run: 1343
Records to be processed at start of migration run: 121
Records to be processed at end of migration run: 121
We applied the note and followed the instructions in the note to restart the SDMI class and it completed successfully.
So, if you are planning an upgrade to 2020 it is wise to upgrade to FPS02 so this note is already part of the stack.
How to turn off SDMI
There are two scenarios where you may want to turn them off
- You just finished upgrade but dont want SDMI to start when you go live
- You have done live, but SDMI classes are failing continuously or there are performance problems
The steps are outlined in SDMI FAQ KBA. In short, you can do two things
- Deactivate the standard job SAP_SDM_EXECUTOR_ONLINE_MIGR in SJOBREPO or
- Configure "Suspend Online Migration" in SDM_MON --> Config Options
Remember, if you are doing this for scenario 1 then you must turn off SDMI before executing btctrns2.
SDMI After a System Refresh
We had to refresh our system QA system for business but we were still troubleshooting the issue with class CL_FINS_SDM_ACDOCA_NETDT.
After the refresh, SDMI wouldn't start despite removing the Suspend Option in SDM_MON. The root cause was the standard job SAP_SDM_EXECUTOR_ONLINE_MIGR was in an inconsistent state.
In SJOBREPO Deactivating and "Activate in all clients" did not help either.
The option "Revert to Standard" helped fix the problem and started the SDMI.
Summary
If you are upgrading to S4HANA 2020
- and you have SAP RAR, the set the parallel processing to 1 wp, immediately after the upgrade but before btctrns2 execution. This will help avoid lock overflow issues with SDMI class CL_SDM_FARR_D_CONTRACT_VERS_CD
- If you still get the lock overflow error, create an incident for SAP
- and have large volume of records and partitions in ACDOCA, it is better to upgrade the HANA DB before S/4HANA upgrade or before you start SDMI to one of following revisions. This will help avoid issues with SDMI class CL_FINS_SDM_ACDOCA_NETDT
- HANA 2.0 SPS05 - Rev 2.00.059.00
- HANA 2.0 SPS06 - Rev 2.00.060.00
- upgrade to FPS 02 to avoid issues with SDMI class
CL_SDM_BALHDR_ALSTATE
Part 1 - https://blogs.sap.com/2021/12/06/s-4hana-upgrade-1809-to-2020-sdmi-lessons-learned-part-1/
Part 2 - https://blogs.sap.com/2021/12/07/s-4hana-upgrade-1809-to-2020-sdmi-lessons-learned-part-2/
Regards
Nanda
- SAP Managed Tags:
5 Comments
