Forum Discussion
Really bad throughput on copy data step copying data from SAP Hana into Lakehouse
- 1 year ago
Hi v-lgarikapat ,
We finally got the SAP Hana connector to work/perform as expected. What ultimately worked for us was to roll back our on-prem gateway version back to the March 2025 (3000.262) version. The April 2025 (3000.266) and May 2025 (3000.270) versions did not work for us. The throughput for those versions was really bad. Below is a screenshot of the throughput after rolling back to March 2025:
Hi Bikematt ,
Thanks for reaching out to the Microsoft fabric community forum
Thanks for your prompt response
Bikematt in addition to Bikematt suggestions below, here are a few troubleshooting steps that may help you resolve the issue.
1.Check the ODBC connector and driver settings. Make sure you’re using the right, up-to-date ODBC driver for SAP HANA. Older or mismatched drivers can seriously throttle performance. Also, double-check the DSN settings like fetch size and timeout settings they matter more than you think.
- Compare the two gateways. You mentioned Synapse and Fabric are using different on-prem data gateways. Here’s a hunch: one might be a rockstar, and the other… not so much. Look at
- CPU and memory usage on each box
- Network speed and any signs of throttling
- Gateway versions (old versions can be bottlenecks)
- Tune the source query. If Fabric is taking forever to “wait for source,” that could mean SAP HANA is choking on the query. Run the same query directly on SAP HANA and see how fast it returns. If it’s slow there too, then maybe:
- The query needs an index or two
- The logic needs rework fewer joins, fewer wildcards, tighter WHERE clauses
- Or the table’s just massive and needs filtering or pagination
- Revisit partitioning. Dynamic range partitioning can save you or sink you. If you’re not partitioning, you’re stuck with single thread pulls. If you are, and performance is still bad:
- Check if your partition column has good spread (no skew)
- Don’t go wild with too many partitions; the gateway will cry
- Check staging settings in Fabric. Some copy activities in Fabric might be defaulting to stage data in intermediate storage before final delivery. That adds overhead. Poke around in the copy settings and see if staging can be toggled off for a test.
- Test small first. Try copying a very small table or subset of rows. If even that’s crawling, it's not the data it’s the setup. This is your baseline test.
- Network and firewall checks. Especially from the Fabric gateway to SAP HANA. Any packet loss, DNS lag, or handshake delay will compound massively over large data copies.
- Peek at logs. Gateway logs and Fabric pipeline activity runs often contain gold nuggets warnings, slow steps, retry attempts. Don’t skip them.
For references
Copy activity performance and scalability guide - Microsoft Fabric | Microsoft Learn
Copy data from SAP HANA - Azure Data Factory & Azure Synapse | Microsoft Learn
Integrate your SAP data into Microsoft Fabric | Microsoft Fabric Blog | Microsoft Fabric
Solved: Re: Write data from Fabric Onelake to SAP on-prem/... - Microsoft Fabric Community
Best Regards,
Lakshmi Narayana
- Bikematt1 year agoFrequent Visitor
Thanks all for the responses and suggestions! I'll review these steps and follow up once we figure out the culprit.
- v-lgarikapat1 year ago
Community Support
Hi Bikematt ,
Thanks for the update! If you have any trouble or need help, just let us know we're happy to support you.
Looking forward to your response.
Best regards,
LakshmiNarayana- Bikematt1 year agoFrequent Visitor
Hi v-lgarikapat ,
We finally got the SAP Hana connector to work/perform as expected. What ultimately worked for us was to roll back our on-prem gateway version back to the March 2025 (3000.262) version. The April 2025 (3000.266) and May 2025 (3000.270) versions did not work for us. The throughput for those versions was really bad. Below is a screenshot of the throughput after rolling back to March 2025: