With SPS06 and even stronger in SPS07 the HEX engine was pushed to be used more often. This results on the one hand side in easy scenario to perfect results with lower memory and CPU consumption ending up in faster response times. But in scenarios with FAE (for all entries) together with FDA (fast data access), it can result in bad performance. After some customers upgraded their first systems to SPS07 I recommended to wait for Rev. 73/74. But some started early with Rev. 71/72 and we had to troubleshoot many statement. If you have similar performance issues after the upgrade to SPS07 feel free to contact us! Our current recommendation is to use Rev. 74 with some workarounds. The performance degradation is extreme in systems like EWM and BW with high analytical workload.

The details of swapping in the context of SAP HANA

Numerous IT projects such as S/4HANA projects or HANA migrations will go live over the Easter weekend. Mostly this tasks will be controlled by the SAP provided SUM tool. The SUM is responsible for the techn. migration/conversion part of the data. Over the past years it become very stable and as long as you face no new issues nearly every technical oriented employee at SAP basis team can successfully migrate also bigger systems. In former times you needed a migrateur with certification which is no longer required. As long as all data could be migrated and the system is up and running the project was successful. But what does the result look like? Is it configured according to the best recommendation and experience? Is it running optimized and tuned?No, this is where the problem begins for most companies. The definition of the project milestone is not orienting on KPIs. It is simply based on the last dialog of the SUM tool, which states that the downtime has ended and all tasks have been executed successfully.

The feature plan stability is not a new one, but can help you in case of an revision update/upgrade, if you recognize big performance degradations. But you have to activate this feature at least 1-2 weeks before the maintenance to capture the SQLs and the execution plan. You can compare the plan performance and apply the execution plan with the best performance. You can also use it as always on feature in daily operations. This may be required due to changes in data over time which may cause the query optimizer to propose different execution plans which may have a negative impact on performance and memory consumption of a query. An additional preparation step can be used to apply filters so that only specific queries are captured. In the background execution statistics are recorded so that the performance of the query can be measured and the best execution plan can

The release S/4HANA 2023 will be the last one with CP. This means the coding based on all the help views has to be adjusted after this release. My recommendation is to use this as target release for the next years! But also keep an eye on the other components. The announcement about the extension of maintenance for Business Suite solutions has no influence on the end of compatibility pack use rights - they will be terminated after 2025. In the exceptional cases of CS, LE-TRA and PP-PI, the usage right to their respective compatibility pack items (cf. matrix) terminates at the end of 2030.

When you are running a S/4HANA system you have to check frequently if all components are still in support. This starts at the hardware level, continues on hypervisor level over OS till the SAP Kernel and the SAP S/4HANA version. The lifecycle of each component is different. So, this means that once a year you have to check this support dilemma. With this little diagram we want to help you to keep your components in sync.

If you are not monitoring your buffer cache (=BC) over your landscape when you are using NSE, you can get serious problems. If the BC is too big, you waste memory and the saving rate drops. This is no big deal but should be avoided. The other way around - the BC is too small - will create some trouble.

DMO used to be heterogeneous (change of DB). Now you can use DMO with system move (also on-prem to target on-prem) to migrate and convert ECC on HANA to S/4 or just update/upgrade S/4 and move it to another location like other DC or other instance in one step. The DMOVE2S4 is just to move and convert to the cloud in one step. This includes also anyDB source systems and downtime-optimization techniques (doDMO and doC).

Der Einsatz von SNC/COD kann in Verbindung mit HANA zu Performanceproblemen und Inkonsistenzen führen. The use of SNC/COD in conjunction with HANA can lead to performance problems and inconsistencies.