Large SAP tables do not fail loudly — they hang. Operators discover stale data at 09:00 when dashboards show yesterday's numbers and nobody received an alert.
The SQL Project Cockpit in iDataEngine gives you levers that map to real engine behavior: package size, parallel processing, transfer method (I/A/U/D/L), and job-level timeout controls introduced in recent releases.
Tuning dimensions that matter
- Transfer method — full refresh (I), append (A), upsert (U), delta by parameter (D/L); wrong method causes duplicates or gaps
- Package size — smaller packages are more reliable on wide tables; larger packages reduce round trips but raise memory use
- Parallel processing — on by default; disable only when SAP or SQL resources are constrained
- Per-project timeout — stop runaway jobs instead of waiting for the nightly batch to block the queue
- Delta parameters — for D/L methods, validate parameter fields exist in the project or saves warn you
Use Test (first-row / first-package) before scheduling. SQL Job Monitor shows package errors with GUID and package ID — you can drill into error text and re-run without guessing.
TSAP note
SAP → SQL projects use SAP background jobs; TSAP (Q/R) reverse transfers run asynchronously on the Java side (concurrency limits apply). Timeout and monitoring semantics differ — tune each direction separately.
Why it matters
Throughput without observability is just faster failure. When timeouts, package sizing, and monitor alerts are configured together, operations teams fix issues in minutes — and business users trust the warehouse again. That is the difference between "we transfer millions of rows" and "we transfer millions of rows on time, every night."