Issue copying from warehouse to Oracle database

Hi kkoba, 

You’re hitting a gateway connectivity/auth quirk specific to Fabric Warehouse.

When a copy activity targets an on-prem Oracle sink via the on-premises data gateway, the gateway machine is involved in the data movement. That box must be able to authenticate to, and open a TLS 1.2 connection on TCP 1433 to, the Fabric Warehouse SQL endpoint (*.datawarehouse.fabric.microsoft.com). If that path is blocked or the Warehouse connection is using an auth mode that isn’t usable from the gateway context, you’ll see “SSL Provider… connection was forcibly closed by the remote host.” See the allowlist and connectivity requirements: Add Fabric URLs to your allowlist, Warehouse connectivity, and gateway comms/TLS details: Gateway communication settings.

Why the difference across your 4 cases:

• Warehouse → Oracle (fails): The gateway must sign in to the Warehouse SQL endpoint and complete a TLS handshake over 1433. If outbound 1433/TLS 1.2 from the gateway to *.datawarehouse.fabric.microsoft.com is blocked/inspected, or the Warehouse connection is using an identity that isn’t valid from the gateway context, login fails. Connector details and supported auth are documented here: Fabric Warehouse connector (copy).
• Oracle -> Warehouse (works): The gateway only has to reach Oracle; writing into Warehouse is handled by the service side using supported methods, so the gateway isn’t the one making an outbound SQL connection to Warehouse. (Same connector doc: Fabric Warehouse connector.)
• Lakehouse -> Oracle (works): Reading from Lakehouse uses Fabric’s service APIs, and the gateway’s job is only to reach Oracle. That aligns with the one-gateway-per-copy rule and why staged patterns are recommended when different connectivity planes are involved: Copy activity in Fabric pipelines.

What to check/fix quickly:

1. Network from the gateway host
   Allow outbound TCP 1433 to the Warehouse FQDN in your region per the allowlist, and ensure TLS 1.2 is enabled end-to-end. Docs: Fabric URL allowlist, Warehouse connectivity, Gateway communication.
   If you have SSL inspection or a proxy on that path, exempt the Warehouse endpoint; SSL interception commonly causes the exact “forcibly closed” error.
2. Warehouse connection authentication
   In the connection used by your pipeline, prefer Service Principal for Warehouse and grant it at least Contributor in the Fabric workspace. This avoids relying on a context that may not exist on the gateway box. Auth options are listed here: Fabric Warehouse connector (auth).
   After updating, re-test the connection and the copy.
3. Oracle prerequisites on the gateway
   Verify the Oracle client prerequisites are installed on the gateway machine (OCMT etc.), since the gateway is the process writing to Oracle: Oracle connector prerequisites.

Need a “works today” pattern while networking is being fixed?
Use a 2-step staged copy:

1. Warehouse -> Lakehouse (service plane).
2. Lakehouse -> Oracle via the gateway.

That design is explicitly recommended when a single copy would need different network planes, and avoids routing Warehouse SQL over the gateway path: Copy activity in Fabric pipelines.

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.