While executive the pipeline in ADF taking long time

Hi @Anandhswarupp The error you're seeing Execution Timeout Expired (Error code 2011) usually means the SQL command in your Script activity is taking longer than expected to complete, and ADF is timing out while waiting for it.

You mentioned the same pipeline used to finish in around 1.5 hours but now runs over 2 hours and fails. That’s a clear sign something changed either in the data volume, query performance, or the database environment.

Here a few troubleshoot steps:

1. Check the SQL in the Script Activity: Try running the same SQL manually in SSMS or Azure Data Studio. See how long it actually takes to complete. Sometimes slowdowns come from more data being processed, blocking, or inefficient query plans. If it's slow even outside ADF, the issue is likely in the query or the database performance.
2. Increase the Timeout: By default, ADF Script activities might have a lower timeout. Go to the Script activity settings and check the "Command timeout" field — try increasing it to something like 3600 seconds (1 hour) or higher if needed. That alone might be enough to let the query complete successfully.
3. Check the Database Performance: Look into whether your SQL server is under pressure — high DTU usage, CPU, or memory can cause long execution times. You can use tools like Query Performance Insight in Azure SQL, or run some DMV queries (sys.dm_exec_requests, sys.dm_tran_locks, etc.) to check if your command is getting blocked or waiting on resources.
4. Tune or Break Down the SQL: If the query is doing heavy joins, updates, or deletes on large tables, consider optimizing it: Check for missing indexes, Update statistics, Break the operation into smaller batches using a WHILE loop or row ranges. Sometimes even a simple change in how you filter or join tables can make a huge difference in execution time.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.

Data is moving from nonprime to azure sql database

@Anandhswarupp Thanks for the additional detail since the data is moving from a non-prime system to Azure SQL DB, network latency could also be a factor here, especially if the source is on-premises or cross-region. That could slow things down unexpectedly.

If the Script activity is running a complex SQL operation (like MERGE or UPDATE), it might be helpful to test it directly in SSMS or Azure Data Studio to confirm whether the delay is within ADF or the query itself.

Also, if not already adjusted, try increasing the Script activity’s Command Timeout (e.g., 3600 seconds or more), and consider breaking large operations into smaller chunks that often helps with performance and reduces the chance of timeouts.

As the query now takes longer than before, it’s also worth checking Azure SQL performance look for blocking, resource waits, or plan regressions using tools like Query Performance Insight or DMVs like sys.dm_exec_requests.

If the logic is getting large or complex, another option is to move it into a stored procedure and call that from ADF easier to manage and optimize within SQL directly.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.

The issue not resolved,

@Anandhswarupp Since the pipeline is still getting stuck at the Script activity and throwing a timeout error, let’s try digging a bit deeper to get to the root of it.

First, run the same SQL script directly in SSMS or Azure Data Studio. This will help confirm whether the delay is due to the query itself or something specific to ADF. If it’s slow even outside of ADF, we’re likely looking at a performance issue within the SQL logic or the database itself.

If your script is doing a complex operation (like a big UPDATE or MERGE), try moving it into a stored procedure. This can help simplify the ADF pipeline and often gives better performance and easier debugging from the database side.

Also, check the Script activity settings in ADF specifically the “Command timeout” value. Make sure it's set to a higher number, like 3600 seconds (or even more, depending on how long the operation typically takes). Sometimes this alone can stop timeouts if the logic is just taking a bit longer.

Since the data is coming from a non-prime source, keep an eye on network latency or any performance bottlenecks with your integration runtime. If you’re using a self-hosted IR or working across regions, even slight network slowdowns can add up during large data transfers.

Lastly, it’s worth checking your SQL Server for anything that might be slowing things down. You can look for blocking sessions, wait stats, or high resource usage using system views like sys.dm_exec_requests or sys.dm_os_waiting_tasks. That can help you see if something else is interfering with your query execution.

If you get a chance to test the SQL script directly or spot anything unusual in the database side, feel free to share more details.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.