Issue copying from warehouse to Oracle database

[kkoba]

Hello everyone.

I'm having issue with a DataFactory pipeline.

Here's the problem:
Objective: Update data from Fabric Warehouse to an on-premises Oracle database.
Writing to the Oracle database is performed through an on-premises data gateway (OPDGW).

The following settings are configured for the Fabric DataPipeline copy activity:
- Source: Table in Fabric Warehouse
- Destination: Table in Oracle database (via OPDGW connection)
* The column definitions of both tables are identical.

The following error occurred during pipeline execution:

ErrorCode=SqlFailedToConnect,
'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,
Message=Unable to connect to SQL database.
For more information, please contact the SQL Server team.
Server: 'XXXXXXXXXX.datawarehouse.fabric.microsoft.com',
Database: '******-******-******-******-******',
User: ''.
Make sure the connection configuration is correct and that the SQL database firewall allows Data Factory Runtime access.

Source=Microsoft.DataTransfer.Connectors.MSSQL,
''Type=Microsoft.Data.SqlClient.SqlException,
Message=A connection to the server was successfully established, but an error occurred during the login process.
(Provider: SSL Provider, Error: 0 - An existing connection was forcibly closed by the remote host.),
Source=Framework Microsoft SqlClient Data Provider, ''Type=System.ComponentModel.Win32Exception,
Message=An existing connection was forcibly closed by the remote host,
Source=,
'

If I swap the source and destination in the copy activity,
data is transferred from the Oracle database to Fabric Warehouse without any errors.
Additionally, if I set the copy activity source to Lakehouse and the destination to an Oracle database, it works fine.

Validation Results

Case	Source	Destination	Status
1	Warehouse	Oracle Database (via OPDGW)	Failure
2	Oracle Database (via OPDGW)	Warehouse	Success
3	Lakehouse	Oracle Database (via OPDGW)	Success
4	Oracle Database (via OPDGW)	Lakehouse	Success

Why am I getting an error when the source is Lakehouse and the destination is an Oracle database (via OPDGW)?

Thanks in advance.

[v-sdhruv]

Hi @kkoba ,
Just wanted to check if you got a chance to review the suggestions provided and whether that helped you resolve your query?

Thank You @tayloramy  for your prompt response t the query.

[tayloramy · Accepted solution]

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.

[kkoba]

@tayloramy 

Thank you for your reply.
We'll implement a solution that works through Lakehouse.
Best Regards,
kkoba