- SAP Managed Tags:
With the fast-approaching end of maintenance coming on December 31st 2027 for SAP ERP 6.0 most customers are in the midst of planning their transitioning to SAP S/4HANA. If the brownfield system conversion is chosen, the business downtime window restriction will be the key deciding factor on potentially whether any downtime-minimization approach will be required.
Enter downtime-optimized Conversion (doC) for the Software Update Manager (SUM) to allow for a single step minimized approach for brownfield conversions that includes migrating to SAP HANA Database while converting to SAP S/4HANA. Starting end of calendar year 2023, DMOVE2S4 is supporting doC for migrating to hyperscaler as generally available under certain restrictions.
While using the doC approach, three long-running Technical Downtime activities are moved partially to the Uptime with only delta remaining for your maintenance window. This delta is one of the main Technical Downtime estimation challenges when working on doC projects as converting non-Production systems won’t have any delta to process. Due to the nature of how the delta is processed, even simulated data on lower landscapes might not be completely representative of what you might found during actual Production Go-Live.
Having a high transactional volume possess an additional challenge when estimating the technical downtime as the business generated data will impact directly and indirectly some of the technical downtime steps (during the SUM Execution Roadmap phases). Following up the impact on the following activities will be explored:
- Uptime migration of tables: downtime-optimized migration of the manually selected application tables during uptime
- Downtime migration of tables: final migration of the application data not selected for uptime migration
- Downtime FI and ML conversions: finance and Material Ledger related delta conversion activities
- Other data conversions: remaining table structure conversions and miscellaneous items to complete the loop
Uptime migration of tables or downtime-optimized DMO (doDMO)
For the uptime migration of tables doC leverages the proven solution in downtime-optimized DMO (doDMO) that can be further explored in following link and note. This is a trigger-based solution which means that before the tables are initially migrated during the SUM Uptime Processing, the tool will create a set of triggers and logging tables for each of the tables so the newly business created data can also be migrated and be available after the conversion is completed. Note that this optimization only can happen when a migration of DB server is part of the maintenance event, either AnyDB to HANA or HANA to HANA leveraging homogeneous DMO.
The delta captured by the triggers on the logging tables is expected to be migrated before the downtime window begins to fully minimize the amount of data that needs to be moved during actual downtime. It is this transfer where the first focus should be, SUM uses its own delta record and replay technology (CRR) and as everything is business as usual, the logging (LT) and logging history (LTH) tables used by the CRR will continuously grow.
In cases like source database being IBM DB2/6, the LT and LTH tables are created as volatile which means no stats are kept for them so the access plan to this tables can and will degrade over time. In consequence the more changes are captured by CRR the slower the access to them will be, the impact can be minimal at first, but the access time will degrade over time primarily in the workload generation step (CRRCOLLECT), so the R3load processes will fetch less chunks per loop and row throughput will slow down.
This is because a VOLATILE table will have certain adjustments made to its statistics. If there are no statistics, DB2 will firstly fabricate some statistics and then modify them slightly. If there are existing statistics, the VOLATILE attribute will ensure the statistics meet certain conditions but will use the existing values as a basis for the adjustments that are made.
The adjusted statics are then used by the optimizer to formulate the access plan just like other tables. If it starts from a reasonably accurate estimation of the data in the table, the decisions the optimizer makes will be more accurate than if all attributes of the data are fabricated. In summary, without reasonable statistics to start with, DB2 will not know if the predicates provided in the query will return 1 row or 1 million rows.
Other SUM steps where the CRR is involved and will be benefitted by having updated stats on the bigger logging and logging history tables are (and not limited to):
- RUN_RRC_REPLICATE_FINAL
- EU_CLONE_MIG_OPTDMO_REPLAY_RUN
- EU_CLONE_MIG_OPTDMO_COUNT
Downtime migration of tables
A separate group of tables are migrated in downtime and don’t have a delta, why a high-transactional volume would impact these tables that don’t have a delta to replicate is a good question. This phase gets impacted as a side effect as the splitting calculation happens as one of the initial steps of the recording window. Any additional extra time used during the recording window for the initial migration and the process of the recorded backlog will degrade the balance of the calculated splits increasing the risk of single long running buckets. Over splitting tables that have this symptom can help mitigate this unbalance in most cases.
In an extreme situation, whenever there is a downtime migrated table that has monotonic growth on the field used in the split condition where clause will have an unusual/unexpected behavior. This means that the range in this field which is evaluated when the splitting is done might differ considerably to the time the actual transfer is done, hence the final package will contain most of the data. For example, EDI40 and EDIDS tables grow on DOCNUM field and by default that’s the one considered for splitting.
In below example, EDI40 had in average 2 million rows in each split before bucket 100 taking less than 2h each, while split 100 migrated more than 59 million rows with a runtime of 19,6h.
Recommendation is to consider these tables for uptime migration if business won’t be impacted by CRR triggers during uptime. The change of the uptime/downtime table groups should be done after thorough analysis as for cases with heavily accessed/changed tables it might be required to fully migrate them in downtime to avoid impacting the system performance to the business during the SUM uptime activities.
FI and ML data conversion
What the SUM processes during the delta steps of the FI and ML comes from a set of protocol tables populated at RUN_RRC_FILLPROTTAB step. Little can be done to reduce the impact of the business to it as it grows almost linearly with keys added/changed during the recording window and that is not something that we can restrict the business on.
For the delta FI step (PARRUN_SMIG_SFIN), I saw that NZP (preparation step to prepare for the Delta data), MUJ (The actual migration of line items into ACDOCA from protocol tables from BSEG or FAGFLEXA, COSP, COSS, ANEX and ANEP) and R23 (the check of the migration of journal entries) were the bigger steps affected by the business load in the cases I worked on, and the number of periods to which the customer was writing the data was an additional important factor. Again, this cannot be restricted easily without additional impact to business, so the actual mitigation opportunities are limited.
But its important to note to accurately plan for the go live window without surprises.
On the ML data conversion side we see a similar situation on step PARRUN_SMIG_DT_MKPF1_INS and PARRUN_SMIG_DT_MKPF1_UPD, In this silent migration (sMIG) phases the newly created/changed material documents during the recording window with header table MKPF and item table MSEG are migrated to the S/4HANA table MATDOC, only mitigation that can be done is making sure enough BTC work process are configured, but it will only be long running if new keys are inserted frequently during the recording window.
On the other hand, step PARRUN_SMIG_DT_FILL_EXTRACT where the table MATDOC_EXTRACT is built from the MATDOC records is purely a downtime step. Runtime will come from the size of MATDOC table and won’t be impacted from the size of the delta generated/migrated, mitigations/optimizations on this phase should be done using the Parallelization Framework (PFW) as note 2351294 states for report NSDM_MIG_FILL_EXTRACT.
Other data conversions
The impact to other conversions steps like RUN_DO_CALL_XCLA_EXEC_DT should be mitigated with PFW configurations as well. While the delta data changes on KONV, VBFA will be kept up to date with triggers as they are part of the “Shadow Field Migration” process.
In summary
A high transactional volume will impact both your uptime and downtime activities while performing a doC conversion but can be partially mitigated with analysis and planning. Uptime activities need to be outlined with the day-to-day activities to avoid any impact on the business, while having a bigger delta and longer recording window will impact the downtime as more data will be required to be processed and other side effects will affect on the downtime phases.
On the below example we ran multiple Load Verification (LV) cycles (executing uptime activities in production and finishing downtime steps in a cloned environment) and I have done my best to isolate all other variables that were changed from cycle to cycle, so using LV1 as baseline it can be seen how the number of recorded changes influenced the runtime.
Finally for the Go Live cycle I have included the mitigation activities in the calculation to showcase how much the runtimes can be reduced for some phases to help balance out the phases that are not so easily mitigated because it would involve restricting the business.
Each delta will grow differently based on business processes and needs, so your experience might vary.
If you are interested to know more, have some other query or excited to apply that knowledge in your conversion journey towards SAP S/4HANA via the above-mentioned Downtime Minimization methods, feel free to let your Technical Quality Manager know about it and copy us at SAP Premium Hub - CoE NA MO Team Inbox <sap_coe_na_mo@sap.com>. Thank you!
1 Comment
