Forum Discussion
Fabric Copy Job Timeout
I have a legacy SQL 2008 server (CDC enabled) and a SQL Server 2025, both have fabric connections and use an on prem data gateway. I'm using the Fabric copy job to incrementally transfer data from the 08 server to the 25 server. This works well for small/medium size tables, however, when I run the job for the first time on large tables (100mil+ rows), the job times out around the 40min mark and returns this error message.
'Type=System.TimeoutException,Message=Dispose resource timeout,Source=Microsoft.DataTransfer.DataContracts,'
I cannot find any reference online as to what this means, could I please get some assistance?
2 Replies
- tayloramy
Super User
Hi joel_delima,
Fabric is not exactly intended to be used to move data from one on prem system to another on prem system.
When this big table is running, what do your resources on the gateway server look like? Are you maxing out your CPU and memory? If so you may need to upgrade your gateway server to add more power.
What you could also try is to split the job into two steps, one to ingest the data from the 2008 SQL into a Fabric datastore like a SQL Database, then a second job to take it from the Fabric database back to your on prem SQL 2025 server.
If your SQL Servers are on the same network, you can also skip fabric directly and create a linked server or external table on the 2025 server that points to the 2008 server and use cross server queries to load the data, this is the approach I would take first.
- DreamITLearn
Advocate II
Hi joel_delima,
this looks like a gateway-side timeout, not an issue with your Copy Job logic itself. A few things point that way:- The error source is Microsoft.DataTransfer.DataContracts, which is the data movement/gateway layer, and "Dispose resource timeout" typically means the connection/resource couldn't be cleanly closed within the allotted time, common when a large initial load keeps a connection open far longer than smaller incremental runs.
- It only fails on the first run on large tables (100M+ rows) because incremental runs after that only move the delta (via CDC), much smaller payloads, so the gateway connection doesn't stay open nearly as long.
Likely causes and fixes:
- On-prem Data Gateway timeout settings - the gateway has its own internal query timeout separate from the Copy Job's settings. Check Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config on the gateway machine for timeout values (similar to the MashupDefaultPoolContainerMaxWorkingSetInMB type settings), these often need to be raised for very large initial loads.
- Gateway resource exhaustion - 100M+ row initial loads can exhaust memory/connections on the gateway VM over a 40-minute window. Check gateway machine resource usage (CPU/RAM) during the run.
- Split the initial load - rather than relying on the Copy Job to pull the full 100M+ rows in one shot, do a one-time manual bulk load (e.g., via a Pipeline Copy activity with partitioning, or BCP/bulk insert) to seed the table, then let the Fabric Copy Job take over for incremental CDC sync going forward. This sidesteps the timeout entirely for the problematic first run.
Option 3 is generally the most reliable fix reported for "first full load fails, incremental works fine" patterns with CDC-based pipelines.