SaaS connectors are the easy half of a Fivetran rollout. Salesforce, HubSpot and Zendesk authenticate with OAuth, sync in an afternoon, and nobody argues about them. The hard half is the systems the business is actually run on: an Oracle database behind a twenty-year-old order platform, or an SAP ECC instance whose data model was designed in Germany in the 1990s and has never been fully explained to anyone in your analytics team.
Those sources are where the valuable data lives, and they are also where Fivetran projects stall. This tutorial covers the mechanics of getting them into a warehouse using Fivetran's HVR-based high-volume replication, which is what sits underneath the Oracle and SAP connectors after Fivetran acquired HVR. If you have already read our Postgres CDC to Snowflake walkthrough, treat this as the enterprise-grade sibling: same idea, considerably more paperwork.
Where HVR fits
Fivetran offers more than one way to pull from a relational database:
- The standard database connectors — fully managed, log-based where the source supports it, good up to fairly serious volumes.
- HVR high-volume agent (HVA) — an agent you run next to the source, reading logs directly, designed for terabyte-scale Oracle, SAP HANA, DB2 and SQL Server estates where the source DBA will not allow a cloud service to hold a long-running session.
- Hybrid Deployment — a Fivetran-managed data plane inside your network. Different mechanism, overlapping motivation. Our hybrid deployment walkthrough covers that path.
Choose HVR when at least two of these are true: the source produces more change volume than a hosted connector comfortably keeps up with; security policy forbids outbound database connections from a SaaS platform; the source is SAP and you need the ERP semantics, not just tables; or you have strict latency targets measured in seconds rather than minutes.
If none of those apply, use the standard connector. HVR is more capability and more operational surface, and taking on the second without needing the first is a bad trade.
Part 1 — Oracle
Privileges and log configuration
Most Oracle CDC projects lose their first two weeks to database privileges, so start this conversation with the DBA on day one, not after the Fivetran trial has begun.
The source database needs:
-- archive logging on, with supplemental logging so updates carry key columns
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
Without supplemental logging, redo records for updates contain only changed columns and no reliable key, and the replication cannot reconstruct the row. This is the single most common cause of "the connector connects but nothing sensible arrives".
Then a dedicated read-only user:
CREATE USER fivetran IDENTIFIED BY "<strong-secret>";
GRANT CREATE SESSION TO fivetran;
GRANT SELECT ANY TABLE TO fivetran; -- or grant per-schema/table
GRANT SELECT ON V_$DATABASE TO fivetran;
GRANT SELECT ON V_$LOG TO fivetran;
GRANT SELECT ON V_$LOGFILE TO fivetran;
GRANT SELECT ON V_$ARCHIVED_LOG TO fivetran;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO fivetran;
GRANT EXECUTE ON DBMS_LOGMNR TO fivetran;
Security teams usually push back on SELECT ANY TABLE. That is fair — grant per-table SELECT on exactly the tables in scope instead, and accept that adding a table later becomes a ticket. Whichever you choose, write it down in the runbook, because a year from now someone will ask why a new table "does not appear in Fivetran" and the answer will be this grant.
Ask the DBA two more questions:
- How long are archived redo logs retained? If retention is 24 hours and your pipeline is paused over a long weekend, the logs it needs are gone and you are into a re-sync. Three to seven days of retention is a reasonable ask, and cheaper than the re-sync.
- Is there a physical standby? Reading from a standby (Active Data Guard) keeps the CDC workload off the primary and is usually the difference between approval and refusal.
Deploying the agent
The high-volume agent runs on a host that can reach the database and the archived log destination — typically a small Linux VM in the same subnet, or the database host itself if the DBA permits it. Outbound TLS to Fivetran only; no inbound ports.
Rough shape of the setup:
- Provision the VM (modest CPU, but give it disk headroom — the agent stages change data locally).
- Install the agent package and register it against your Fivetran group; registration produces a token that pairs the agent with your account.
- Create the connection in Fivetran, selecting the high-volume Oracle service and the registered agent.
- Run the setup tests. They check privileges, supplemental logging and log access, and their failure messages are specific — read them literally rather than guessing.
Monitor agent disk usage from the first week. If the destination or network stalls, the agent buffers to disk, and a full disk turns a delay into an outage.
Choosing tables
Oracle schemas behind old applications are full of *_TMP, *_BAK_2019 and audit tables that churn constantly and are of no analytical interest. Those tables are pure cost: churn is what drives monthly active rows, as covered in our connection-level MAR guide.
Set schema change handling to block new tables by default, then enable tables deliberately. Before enabling anything large, estimate its churn:
SELECT COUNT(*) AS rows_changed_last_30d
FROM orders
WHERE last_modified_dt > SYSDATE - 30;
That count is a decent proxy for the monthly active rows the table will generate in steady state. Add the full row count once for the initial load. Do this for your ten biggest candidates and you have a defensible forecast before anyone signs anything.
Part 2 — SAP
SAP is a different kind of problem. The database part is ordinary; the data model is not.
Which SAP are you actually connecting to?
Establish this before any technical work:
- SAP ECC on Oracle / DB2 / SQL Server / HANA — replicate at the database layer.
- SAP S/4HANA on HANA — same idea, different (and rather more normalised) tables.
- SAP Business One, SuccessFactors, Concur, Ariba — application-level connectors, not this article.
Also confirm, in writing, that your SAP licence permits direct database read access for replication. This is a commercial question, not a technical one, and it has stopped projects late enough to hurt. Get it answered in week one by someone who owns the SAP contract.
Cluster and pool tables
This is the detail that surprises everyone new to SAP data.
Classic SAP stores some data in pool and cluster tables — physical tables holding compressed, serialised payloads for several logical tables. BSEG, the accounting document line item table, is the famous one: in ECC it lives inside cluster RFBLG. Read it with a naive database-level replication and you get binary blobs, not columns.
Fivetran's SAP support handles the decoding, and this is precisely why you use an SAP-aware connector rather than pointing a generic Oracle connector at the SAP schema. When you scope the project, list the logical tables the business needs — BKPF, BSEG, VBAK, VBAP, LIKP, MARA, MARD, EKKO, EKPO — and verify each against the connector's supported-table documentation before you promise anything.
In S/4HANA much of this is simplified: BSEG data is available through ACDOCA, the universal journal, and cluster decoding matters less. Knowing which world you are in changes the whole table list.
Do not try to model SAP in the warehouse yourself
The second SAP trap is scope. A team lands 400 SAP tables and then discovers it needs somebody who can explain that MANDT is the client identifier, that you filter to your production client, that MATNR is padded with leading zeros in some tables and not others, and that a sales order's status is derived from three tables and a status flag string.
Two defences:
- Start with one business process. Order to cash, or procure to pay. Perhaps 25 tables, one dashboard, one owner who will confirm the numbers match SAP's own reports. Expand after that reconciles.
- Put an SAP-literate person on the modelling. Not necessarily full time, but the finance or logistics analyst who has lived in these transactions for a decade will save you months. This is genuinely where an external Fivetran team earns its fee — the extraction is a solved problem, the semantics are not.
Build transformations on top in dbt as usual; our dbt transformations service page describes the pattern we use.
Part 3 — the initial load
For a large ERP the first sync is the riskiest moment, for both the source system and the invoice.
Sequence it. Do not enable 200 tables at once. Start with dimension-like masters (MARA, KNA1, customer and material data) — small, stable, immediately useful. Then one transactional table at a time, largest last.
Time it. Run the big historical loads outside the source system's peak. Even a log-based approach reads the base tables once, and that read competes with the ERP's own workload.
Bound it where you can. Ten years of accounting line items rarely earns its keep. If the connector or a source view lets you constrain history — and if the business genuinely only reports on three years — take that option. Every historical row you skip is a monthly active row you never pay for, and history can be backfilled later far more cheaply than it can be deleted from a bill.
Watch the free-use window. New connections have a limited free-use period. Doing your big initial loads inside it is a real saving, so plan the sequencing around that window rather than discovering it afterwards.
Part 4 — validating the result
ERP data gets used for numbers that people are accountable for, so validate more rigorously than you would for a marketing source.
Row counts per table, source versus destination, run daily during stabilisation:
-- source (Oracle)
SELECT COUNT(*) FROM ORDERS WHERE created_dt < TRUNC(SYSDATE);
-- destination (Snowflake)
SELECT COUNT(*) FROM RAW.SAP.ORDERS
WHERE created_dt < CURRENT_DATE() AND NOT _fivetran_deleted;
Remember _fivetran_deleted: soft-deleted rows remain in the destination and will inflate every count you write until you filter them.
A financial control total. Sum a monetary column for a closed period on both sides — a closed accounting period should be immutable, so any drift is a replication problem, not a business one:
SELECT gjahr, monat, SUM(dmbtr)
FROM RAW.SAP.BSEG
WHERE NOT _fivetran_deleted
GROUP BY gjahr, monat
ORDER BY gjahr, monat;
Reconcile that against the equivalent SAP report and have the finance owner sign it off. That signature is what makes the warehouse usable for reporting rather than merely populated.
Freshness monitoring. Alert on _fivetran_synced lag per table rather than only on connection failure — a connection can be green while one table quietly falls behind. Our pipeline observability walkthrough sets that up from the Platform Connector.
Part 5 — operating it
Things to build into the runbook before go-live:
- Log retention alarm. If archived redo retention is shorter than your worst-case pause, you are one incident away from a re-sync. Alert when replication lag approaches the retention window.
- A planned re-sync procedure. Sooner or later you will need one for a specific table. Know in advance what it costs and who approves it — see our schema drift and re-sync playbook.
- Change coordination with the ERP team. SAP transports and Oracle application upgrades change table structures. Ask to be on the change-notification list; discovering a structural change from a broken dashboard is the expensive way.
- Agent patching. The high-volume agent is software you now run. Own its upgrade cadence rather than leaving it on the version installed at go-live.
- PII. ERP systems are full of personal data — employee records, customer addresses, bank details. Exclude or hash at the connector, before it lands. Our column blocking and hashing guide covers the mechanics.
A realistic timeline
For a first Oracle or SAP source, plan roughly:
- Weeks 1–2: privileges, licence confirmation, network path, agent host provisioning. Mostly other people's calendars.
- Week 3: agent deployed, connection created, setup tests passing, small master-data tables syncing.
- Weeks 4–5: sequenced historical loads, table by table.
- Weeks 6–8: validation, reconciliation, first modelled business process, sign-off.
Teams that try to do this in two weeks usually spend the saved time twice over in a re-sync and a credibility problem with finance. The slow parts are approvals and semantics, not technology.
If you are scoping an Oracle or SAP source into Snowflake, Databricks or BigQuery and want the privilege list, table scope and cost forecast settled before the trial clock starts, our data integration and migration teams do this regularly — get in touch with your source systems and rough volumes and we will tell you what the first eight weeks look like.