Skip to main content
Question

Execution packages stuck at 0 current tasks completed while causing 100% repository usage


Hello,

TimeXtender 20.10.51

I’m looking for support with an issue we’re experiencing where execution packages are running but no tasks are being completed while causing 100% usage on the repository.
 


After deploying to production, we ran a package manually and noticed it not proceed past the above step. The “current tasks completed” stayed at 0, and no data was being loaded, even after waiting up to 30 minutes. We tried running it multiple times, but nothing changed. Running individual tables worked fine.

We checked the SQL database usage for the DSA to be sure, and it wasn't being affected—no data was loading as expected.

While troubleshooting, we found that the repository (a standard 100 DTU Azure SQL database) was hitting 100% data IO and DTU usage. One query, in particular, was using nearly all the available resources. It was this query:

(@ObjectId uniqueidentifier)SELECT [StepId], AVG(DATEDIFF(s, [Start], [End])) AS [AvgSeconds] FROM [dbo].[ExecutionPackageLogDetails] WHERE [ObjectId] = @ObjectId AND [Start] IS NOT NULL AND [END] IS NOT NULL GROUP BY [StepId]

Anyone know exactly what this query is? If I was to guess, it’s created in regards to execution packages logging?

We increased the repository to 200 DTU but it still got stuck and reached 100% usage. Interestingly, our test environment is an exact copy of production. It uses the same repository setup (yet only 100 dtu) and scheduled loads, but the same query runs there with much lower IO usage. 
 

This is the test repository looking over 7 days.

 

This is prod

 


Like I said, these environments are 1 to 1 and running exactly the same amount of loads every day. I can’t find any explanation for this. 

Anytime we start a package the repository instantly goes to 100% in prod and drops to 0% when we stop the package.

Anyone here experience something similar or knows why running a simple execution package can sink an entire repository database? 

Appreciate any help or support if anyone has any insight. 
 

8 replies

rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • TimeXtender Xpert
  • 698 replies
  • May 26, 2025

Hi,

 

if you change your execution package tiono longer “Log Execution time” does it complete normally?

I would check if there are deadlocks being reported on the Azure SQL DB hosting your repository and having a look at wait stats / resource consuming queries in the query store. Perhaps some other process is also accessing the relevant tables. 

If your repository has similar rowcounts for production and test and behaves differently, that is somewhat strange.


  • Author
  • Participant
  • 22 replies
  • May 26, 2025

I created a new package with the exact same setup and it worked, which is in itself a even bigger mystery. This is not one of the scheduled packages, so I will have to see how it looks tomorrow after the others have ran and how they went.

I can find no deadlocks on the DB in any logs or metrics. The query store has a lot of entries, but the above query is the biggest one by light years, and nothing else comes close. 

Below is a summary of top data io querys over the past 7 days. The query I linked is the top one here.
 

 


rory.smith
TimeXtender Xpert
Forum|alt.badge.img+7
  • TimeXtender Xpert
  • 698 replies
  • May 26, 2025

Hi,

there is a rule of thumb that pinning an Azure SQL DB to 100% on I/O resources tends to lead to strange behaviour from time to time. It could be that there is something strange in your repository database, perhaps logging a support ticket and sending a bacpac over would be a good idea?


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

​Hi @Victor which service tier are you using?

We have seen in the past that increasing DTU does not necessarily resolve these types of issues, if the IO is being overloaded increasing the service tier of the database typically resolves this issue. Can you please try to set service tier to premium?

 


  • Author
  • Participant
  • 22 replies
  • June 5, 2025

I can try this option and see the result, but the big question is why the test repository and the prod repository has such a large difference in performance. The environments are the same (1 to 1 copies at this time) and the test repository is using significantly less power of a weaker database while doing the same tasks. 

For example, without the 200 DTU on prod the execution packages takes 30-40% longer then the exact same packages in test, because it takes every package so long to start because it hits 100% usage and it just sits there most likely writing to the database before eventually starting the actual loads.

This is something recent and has not always been the case.


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@Victor can you please try upgrading to the latest version of 20.10?


  • Author
  • Participant
  • 22 replies
  • June 5, 2025

Update is planned for the coming weeks to see if it helps


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@Victor also please consider cleaning up execution logs (go to Tools, Repository Administration, and delete old execution package logs) as well as contacting a dba to review SQL db settings and logs

 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings