Sizing is an integral part of the SAP HANA migration process. Be it an SAP Business Suite on SAP HANA or an SAP S/4HANA conversion project. The first look of sizing is provided by the sizing report /SDF/HDB_SIZING. It is important to understand that the sizing report as per SAP Note 1872170 provides not only the output of what the SAP HANA instance size would look like, but it also provides potential for Data Reduction.
With SAP RISE migration to SAP PCE (Private Cloud Edition), few important points should be noted before the start of the migration cycle.
As part of SAP Best Practices, it is important to note, sizing is an iterative exercise in any project and SAP recommends revisiting/recalculating sizing at different phases of the project.
Now, In my project, before we started the execution of the cycles, I performed a sizing exercise which determined the Development system was undersized in SAP HANA and that Production sizing was at a risk of exceeding the initial sizing calculation performed by the time we reach cutover and GoLive.
Note: In my experience, the top 10 tables usually cover the bulk of data to be migrated.
Not only this but looking into the SAP EWA reports, it was also identified that the source system had massive LOBs (large Objects) which will impact the migration dump size calculation and later on the migration downtime as well.
Table TST03 and SOFFCONT1 being problematic tables here.
Having identified these issues early on, we had time to tackle them head-on rather than scurry at the last moment.
In an ideal scenario the customer would have conducted an SAP DVM exercise and would know how to deal with the tables however we do not live in an ideal world and for those customers who did not have an SAP DVM exercise, it is up to the Architects to provide the solutions to fix issues before they become a showstopper for the project.
Based on the above information, I usually classify data as
One can check SAP DVM Guide or SAP Note 23884843 to find out the low hanging fruits which can be easily rectified esp. technical tables like TST03, DBTABLOG etc.
Business Tables like in this case e.g., SOFFCONT* require more Business and functional involvement and long-term strategy like Archiving
Once the above activities were performed, the sizing reports were executed closer to the Dress Rehearsal to understand the SAP HANA instance size.
After Data Clean-up (Report executed June 2022)
Not only did we manage to reduce the data for migration and therefore the technical downtime, this also lead to reduction of the SAP HANA instance size which also impact the cost for the customer.
Happy days!
In conclusion, the earlier one can start with this exercise of data reduction the better are the chances of positive outcomes w.r.t data cleanup.
For more details on DVM refer to the following blogs:
Manage your data volume effectively through data volume management by silvia.gaber
and SAP Help Portal
With SAP RISE migration to SAP PCE (Private Cloud Edition), few important points should be noted before the start of the migration cycle.
- SAP PCE is sold in fixed sizes for the DEV, QA, PRD systems
- Migration Dump is roughly calculated as 20-30% of the size of the DB
As part of SAP Best Practices, it is important to note, sizing is an iterative exercise in any project and SAP recommends revisiting/recalculating sizing at different phases of the project.
Now, In my project, before we started the execution of the cycles, I performed a sizing exercise which determined the Development system was undersized in SAP HANA and that Production sizing was at a risk of exceeding the initial sizing calculation performed by the time we reach cutover and GoLive.
Report Executed Sep 2021
Top Tables
Note: In my experience, the top 10 tables usually cover the bulk of data to be migrated.
Not only this but looking into the SAP EWA reports, it was also identified that the source system had massive LOBs (large Objects) which will impact the migration dump size calculation and later on the migration downtime as well.
LOBs from SAP EWA Report
Table TST03 and SOFFCONT1 being problematic tables here.
Having identified these issues early on, we had time to tackle them head-on rather than scurry at the last moment.
In an ideal scenario the customer would have conducted an SAP DVM exercise and would know how to deal with the tables however we do not live in an ideal world and for those customers who did not have an SAP DVM exercise, it is up to the Architects to provide the solutions to fix issues before they become a showstopper for the project.
Based on the above information, I usually classify data as
- Data in the tables that can be reduced by means of deletion – aka technical logs not required after certain no. of days.
- Data in the tables that can be reduced by means of archiving esp. LOB that cannot be compressed during R3load migration to SAP HANA , usually comprises of images, pdfs stored in the tables at disk level in non- SAP HANA Databases.
One can check SAP DVM Guide or SAP Note 23884843 to find out the low hanging fruits which can be easily rectified esp. technical tables like TST03, DBTABLOG etc.
Business Tables like in this case e.g., SOFFCONT* require more Business and functional involvement and long-term strategy like Archiving
Once the above activities were performed, the sizing reports were executed closer to the Dress Rehearsal to understand the SAP HANA instance size.
After Data Clean-up (Report executed June 2022)
Not only did we manage to reduce the data for migration and therefore the technical downtime, this also lead to reduction of the SAP HANA instance size which also impact the cost for the customer.
Happy days!
In conclusion, the earlier one can start with this exercise of data reduction the better are the chances of positive outcomes w.r.t data cleanup.
For more details on DVM refer to the following blogs:
Manage your data volume effectively through data volume management by silvia.gaber
and SAP Help Portal
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 7 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
