Large Table Seeding
The table everyone said couldn't be extracted.
Now it can.
BSEG. Accounting document line items. Billions of rows in a mature SAP system. A single SELECT times out. Dialog work processes saturate. Basis kills the job. The project moves on without the data.
Every enterprise SAP customer has a version of this story. DataXover ends it.
The Problem
It isn't a tooling problem. It's an architecture problem.
SAP's dialog work process model was designed for transactional operations — short-lived, bounded, user-initiated. A SELECT against BSEG with two billion rows is none of those things. It runs until SAP kills it, until the work process timeout fires, or until a Basis administrator with a monitoring transaction ends it manually.
The problem isn't that the data can't be extracted. The problem is that every approach tries to do it in a single operation or uses the wrong work process type.
DataXover solves both.
How It Works
Chunked. Staged. Concurrent. Resumable.
DataXover opens a database cursor on the target object and reads records in configurable package-sized chunks. The package size is yours to set — tune it to your system's available background work process capacity and your maintenance window constraints.
Each chunk writes to a single compressed file on the SAP application server file system. The next chunk. The next file. Sequentially, until the entire object has been read.
Background jobs only. Dialog work processes untouched. Your users experience nothing.
No single SELECT ever attempts to read the whole table. No timeout. No work process saturation. No Basis intervention required.
Every compressed file written to the file system is individually tracked. The file system is the work queue — it knows exactly which files have been completed and which remain.
This design enables everything that follows.
Seeding a two billion row table doesn't require a single uninterrupted execution window. Run during your maintenance window tonight. Pause when the window closes. Pick up tomorrow night from exactly where you left off.
The system reads the file system state at the start of each run and determines the next file to process. Progress is never lost between runs. There is no ambiguity about where the seeding process stands at any point.
If a problem occurs at file 134 — network interruption, target database issue, anything — restart from file 130. Or file 120. Or any prior point. Delivery uses upsert logic — records already delivered are safely overwritten with identical data. No duplicates. Nothing is lost. No work is repeated unnecessarily.
As compressed files are written to the file system, they begin uploading to the target database while additional files are still being generated on the SAP side. Extraction and delivery run simultaneously.
The execution engine creates the landing table from the first file received — schema, data types, all of it — and processes subsequent files as inserts. Your destination database starts receiving data long before SAP-side extraction is complete.
The result: significantly reduced overall elapsed time compared to sequential extract-then-load approaches.
30 million records. Three tables concurrent. 15 minutes. Decade-old ECC. Single-threaded per table.
That's not a benchmark — that's Tuesday.
S/4HANA benchmark on modern AWS infrastructure in progress. Results published when available. The architecture that produced these numbers on old hardware performs significantly better on modern infrastructure with separated app and database tiers, HANA columnar storage, and parallel job execution.
What Happens Next
Seeding is the beginning. Not the end.
DataXover captures a timestamp at the moment seeding begins. When the last file is processed and delivered — however many runs that takes, however many nights — CDC starts automatically.
The timestamp captured at the start of seeding marks the point from which change capture begins. No changes occurring during the seeding window are lost. No manual switchover. No gap in the change record.
The table that took days to seed is now in your destination database with continuous change data capture running. Initial full load and ongoing delta extraction managed as a single unified pipeline.
You configure the profile. DataXover handles the transition.
The Bigger Picture
Every mature SAP system has tables that have never been extracted at full volume.
BSEG is the canonical example. But it isn't the only one. CDPOS — the change document items table — grows continuously and can reach billions of rows on active systems. ACDOCA in S/4HANA, the universal journal, holds the complete financial history of the business. These tables contain some of the most analytically valuable data in the enterprise. They have been effectively inaccessible for bulk extraction.
DataXover seeding makes them accessible.
Not with a workaround. Not with a custom development project that takes months and breaks in production. With a profile configuration, a package size setting, and a schedule.
The data your analytics team has been asking for — the historical depth that makes the difference between surface-level reporting and genuine business intelligence — is in those tables.
Now it can get out.
Architecture
No external tooling.
Everything described above runs inside your SAP ABAP runtime.
No middleware. No external scheduling tools. No additional infrastructure on the SAP side. The same ABAP transport that handles all other DataXover operations handles seeding. The same background job framework. The same Admin Console monitoring.
One transport. One platform. The table that couldn't be extracted is a profile configuration away.
Background jobs only.
Pause, resume, recover.
CDC when it's done.
That's the answer to the question your analytics team stopped asking.
Request Consideration