BI Expert author Dr. Bjarne Berg and his COMERIT colleagues Rob Frye, Jesper Christensen, and Joe Darlak took part in a live Q&A on SAPinsider Onlineto discuss how to quickly move your SAP Business Warehouse (SAP BW) system to SAP HANA using the database migration option tool. An edited selection of answers to SAP customer questions about migrations, sizing, and performance appears below.
Q: Should we expect to experience any performance issues during migration?
Joe Darlak: There are many factors that impact performance during migration.
First, it is extremely important to test your actual production hardware prior to the production migration. We strongly recommend planning a "dry-run" migration cycle — migrating a copy of your production system to the production hardware and "smoke-test" the hardware to ensure there are no bad components that can affect performance or stability.
Second, network bandwidth between the SAP BW source system on the legacy database and the SAP BW target system on SAP HANA should be 10Gbps or higher. If the systems do not share the same VLAN in your data center, this could also be a problem.
Third, the number of cores and memory capacity of your SAP BW source system will limit the export performance of the migration. If you adopt a downtime-minimized approach, be sure to size your interim hardware appropriately.
Q: After database migration, what percentage of performance improvement can we expect when using a database optimization technique for a database size of 10TB?
Joe Darlak: From our experience with SAP BW databases of 10TB, we see data loading performance improvements of up to 40% simply by migrating to SAP HANA without any LSA optimization. From a reporting perspective, we see queries run 16X faster, on average.
Q: Do you have any advice on sizing the SAP HANA system?
Jesper Christensen: That’s another great question! There are several methods for sizing an SAP HANA system, including the “t-shirt” sizing model and the rule-of-thumb sizing approach, but the preferred — and most accurate — method is to use the SAP BW on SAP HANA sizing tool, which is included in the SAP BW migration cockpit for SAP HANA. You can find the complete instructions for downloading the ABAP code for the migration cockpit in SAP Note 1909597. For information about sizing SAP Business Suite powered by SAP HANA, see SAP Note 1872170.
Q: With SAP HANA, are there changes needed in extract, transform, and load (ETL) programs?
Rob Frye: Good question. Some transformations can actually be slower in SAP HANA than in legacy SAP BW systems. If you encounter these types of problems, you can improve the performance with SAP HANA hints in the ABAP code (see SAP Note 1662726) or by deleting the filter in the SQL statement and executing the filter in the ABAP engine from unfiltered data returned by SAP HANA (see SAP Note 1740373). Thanks for the question!
Q: Is there a performance impact on an SAP ECC system running on an Oracle database when using SLT (DMIS add-on) to replicate data from SAP ECC to SAP HANA? If there is a performance impact, do we have an alternative solution?
Jesper Christensen: There is a slight performance impact, as the replication runs jobs to transfer the data to the SLT server. From our experience, the impact has been minimal, as the transfer is very quick and the number of data records is limited if replications take place every 10 seconds. In one project, we analyzed the impact in detail; the impact was less than 1% of the SAP ECC system resources were used for replication.
Q: Can we virtualize the hardware with an SAP HANA implementation?
Rob Frye: Yes, there are several providers of SAP HANA in the cloud such as Amazon Web Services, Virtustream, IBM, HP, and of course SAP with their SAP HANA Enterprise Cloud offering.
Dr. Berg: I’d like to add a quick note on performance. For the past seven months, my team has been part of a very large SAP HANA migration for a Fortune 100 company. This total migration moved almost 60TB of data into an SAP BW 7.4 powered by SAP HANA environment, which we then benchmarked against the legacy system. The previous system was standard SAP BW 7.3 running on Oracle. Comparing results between the systems provided us a clear indication of the SAP HANA system benefits:
We tested over 75 queries across seven different business areas and found that SAP HANA was an average of 13.9 times faster than the legacy Oracle system. The average run time across all queries was brought down from 162 seconds on Oracle to just over 15 seconds on SAP HANA.
Certain areas that were tested revealed improvements that well surpassed the average. We noted examples of very large queries that took over 10 minutes to run on Oracle that were executed in one second or less on SAP HANA — nearly 700x faster.
The majority of the query performance came from the data manager, which was 28x faster at query runtime when compared to Oracle. OLAP processing time was also cut in half on SAP HANA.
Several hundred data load jobs were also tested during this benchmark. No changes were made to the data loads going into the SAP HANA environment. We saw an overall performance increase of 52% for data loads into SAP HANA vs. the Oracle environment. Significant improvements were found in the data activation portion of the loading process with some activations being performed over 250x faster than their Oracle counterparts. As an example, the financial stream realized an 85% improvement in total data load times with a large portion of that improvement coming from the data activation stage.
Overall, these numbers represent a significant improvement across the board. SAP HANA outperformed Oracle in every metric we tested it against, and provided some of the best results that we’ve seen, including query performance that is 694x faster in some cases.
For more on this topic, check out the BI Expert anthology “Enhance Your BI Reporting Skills.”