sap-client-copy-acceleratorlisted

# SAP client-copy accelerator (HANA & Oracle) **Field-proven.** Developed on a live S/4HANA QA refresh where ACDOCA (105 M rows) aborted twice in the copy and would otherwise have taken ~13 h single-stream. Result: **~70 min remote** (cross-system HANA SDA, ~1.59 M rows/min, ≈14× the copy) and **~6 min local** (same-tenant). Marks: **[V]** verified against SAP documentation, **[F]** proven in the field on that refresh, **[G]** cited but not read in full. > ## Why the copy is slow — the number that explains everything > > SAP's own guidance, **Note 2163425**: *"the database interface limits the throughput to > **100 – 500 MB/hour**"*, producing *"a correspondingly longer runtime (**up to several weeks**) for > productive clients."* **[V]** > > That is the copy **framework's** ceiling, not your database's. The copy ships rows through ABAP work > processes and (for SCC9) RFC. A modern HANA or Oracle system will move the same rows one to two > orders of magnitude faster when you let it do the work itself. **The table is not the problem; the > transport mechanism is.** **The one structural limit that makes this technique necessary:** the client copy parallelises **across tables, not within one**. Once every other table is done, your last big table is a **single stream** and no amount of extra work processes helps (Note 541311 Q4) **[V]**. That is why one table can hold a whole refresh hostage. --- ## 0. Do these in order — do not skip to the bypass Bypassing the framework is