Forum Discussion
Data Factory runtime is busy error when mirroring tables from on-prem SQL Server on Trial capacity
Hello Team,
We are trying to mirror a few tables from an on-premises Microsoft SQL Server to Fabric using the Data Mirror feature.
However, we keep encountering this error:
"The database cannot be mirrored to Fabric due to below error: Test connection failed. The Data Factory runtime is busy now. Please retry the operation later.
We have followed the common advice to wait and retry after a few minutes, but even after waiting for several hours, the issue persists without any improvement.
We are currently on Trial capacity.
Has anyone faced this persistent issue or found any workarounds to reliably mirror data from on-prem SQL Server under trial or limited capacity conditions?
Any guidance or suggestions would be greatly appreciated!
Thank you.
Hey hemanthsmg ,
This error is happening because mirroring from on-prem SQL Server to Fabric uses Data Factory Integration Runtime (IR) behind the scenes, and in Trial capacity the compute allocated to Data Factory is very limited and shared. When it says “Data Factory runtime is busy”, it usually means the managed Integration Runtime assigned to your workspace does not have available capacity to spin up the connection test or replication pipeline.
In Trial capacity, this can persist for hours because resources are throttled and shared across many tenants. So even if you retry later, the backend runtime may still not allocate compute.
Here are the practical things you can check and try:
First, confirm whether you are using a Self-hosted Integration Runtime installed on-prem. For on-prem SQL Server mirroring, you must install and register a Self-hosted IR on a local machine that has access to the SQL Server. If you are relying only on the default managed runtime, connection tests will fail.
Second, verify the Self-hosted IR status:
- Go to Fabric → Data Factory → Manage connections → Integration runtimes
- Ensure the runtime shows Online
- Check that it is not overloaded (CPU/memory on that server)
Third, Trial capacity has strict limits on:
- Parallel activities
- Compute allocation
- Data movement throughput
If multiple pipelines, notebooks, or test attempts are running, they may consume the limited runtime slots. Stop any other Fabric activities and retry.
Fourth, reduce the load:
- Try mirroring only one small table first
- Disable “Automatically mirror future tables”
- Avoid selecting many large tables during initial test
If even a single small table fails with the same runtime busy error, then it is almost certainly Trial capacity throttling.
The most reliable solution in this scenario is upgrading to a paid Fabric capacity (F SKU). Trial environments are not designed for sustained mirroring workloads, especially from on-prem sources.
As a workaround under Trial:
- Use Dataflow Gen2 to copy a small dataset first
- Or manually test connection via Data Factory pipeline before enabling mirroring
- Restart the Self-hosted Integration Runtime service
In summary, this is typically not a SQL Server issue. It is a capacity/runtime allocation limitation in Trial Fabric. If the error persists for hours even for small tables and the Self-hosted IR is healthy, upgrading capacity is usually the only stable resolution.
If this explanation helped, please mark it as the solution so others can find it easily.
If it helped, a quick Kudos is always appreciated it highlights useful answers for the community.
Thanks for being part of the discussion!
5 Replies
- MohdZaid_
Super User
Hey hemanthsmg ,
This error is happening because mirroring from on-prem SQL Server to Fabric uses Data Factory Integration Runtime (IR) behind the scenes, and in Trial capacity the compute allocated to Data Factory is very limited and shared. When it says “Data Factory runtime is busy”, it usually means the managed Integration Runtime assigned to your workspace does not have available capacity to spin up the connection test or replication pipeline.
In Trial capacity, this can persist for hours because resources are throttled and shared across many tenants. So even if you retry later, the backend runtime may still not allocate compute.
Here are the practical things you can check and try:
First, confirm whether you are using a Self-hosted Integration Runtime installed on-prem. For on-prem SQL Server mirroring, you must install and register a Self-hosted IR on a local machine that has access to the SQL Server. If you are relying only on the default managed runtime, connection tests will fail.
Second, verify the Self-hosted IR status:
- Go to Fabric → Data Factory → Manage connections → Integration runtimes
- Ensure the runtime shows Online
- Check that it is not overloaded (CPU/memory on that server)
Third, Trial capacity has strict limits on:
- Parallel activities
- Compute allocation
- Data movement throughput
If multiple pipelines, notebooks, or test attempts are running, they may consume the limited runtime slots. Stop any other Fabric activities and retry.
Fourth, reduce the load:
- Try mirroring only one small table first
- Disable “Automatically mirror future tables”
- Avoid selecting many large tables during initial test
If even a single small table fails with the same runtime busy error, then it is almost certainly Trial capacity throttling.
The most reliable solution in this scenario is upgrading to a paid Fabric capacity (F SKU). Trial environments are not designed for sustained mirroring workloads, especially from on-prem sources.
As a workaround under Trial:
- Use Dataflow Gen2 to copy a small dataset first
- Or manually test connection via Data Factory pipeline before enabling mirroring
- Restart the Self-hosted Integration Runtime service
In summary, this is typically not a SQL Server issue. It is a capacity/runtime allocation limitation in Trial Fabric. If the error persists for hours even for small tables and the Self-hosted IR is healthy, upgrading capacity is usually the only stable resolution.
If this explanation helped, please mark it as the solution so others can find it easily.
If it helped, a quick Kudos is always appreciated it highlights useful answers for the community.
Thanks for being part of the discussion!
- AnonymousNot applicable
Hi hemanthsmg
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you. - AnonymousNot applicable
Hi hemanthsmg
May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.
Thank you - hemanthsmgFrequent Visitor
Thank you for your suggestion.
When we try to connect or mirror data from an on-premises SQL Server to Microsoft Fabric, the initial connection works, but after some time, it starts showing errors.
As MohdZaid_ mentioned, we have tried to avoid running multiple operations simultaneously to prevent performance issues. We also noticed that the database user requires both DBO and DB server state permissions to successfully mirror table data. After providing these permission it start working as expected.
- AnonymousNot applicable
Hi hemanthsmg ,
We really appreciate your efforts and for letting us know the update on the issue.
Please continue using fabric community forum for your further assistance.
Regards