Skip to main content
To homepage To homepage

Recently we have been running into big problems with our production repository database becoming completely unresponsive after completing an environment transfer, actually leading to scheduled executions not starting the following night.

It has happened twice in the last two weeks but never before during the 3 years that we’ve been working with TX.

The issue is seemingly resolved having switched to a vCore model on the production repository, but we are at a loss as to the root cause of this problem.

We have of course read all the relevant knowledge base articles/community discussions that talk about why the repository may become generally slower over time (execution logs have been deleted, yes) -however, for us it has not been gradually deteriorating but suddenly. Also, we believe our projects are not that big (see below) to warrant the export-import procedure.

Setup

  • TX version 20.10.25.64
  • Multiple environment setup (Dev + Prod), TX running on single Azure VM and all databases are Azure SQL DB.
    • Dev repo, size 4.5 GB, DTU S1 (20 DTUs); Prod repo 12 GB, formerly DTU S2 (50 DTUs), now General Purpose 5 series 2vCores.
  • Prod environment has scheduled executions every night/morning, whereas Dev is running a few times a week.
  • Two projects, where the project versions are at 1490 and 800 respectively in Prod (much higher in Dev). 

At face value, the cause of the problem is that Data IO is hitting the roof and sinking the whole database. But we cannot understand why this happens, when the only thing we do is a standard environment transfer (which we have done thousands of times by now).

Followup question: 

  • Why is the Prod repository so much bigger than Dev, even though Dev has more than 7 times more versions, and the execution logs in Prod have been truncated to just include data from May 2025 onwards?
    • Looking into the database directly, we can see that the DataFields table is close to 6 GB in Prod, but less than 300 MB in Dev. Based on the Query insights advisor in Azure - this table is also one of the most commonly queried one, so there is a suspicion that it might be part of the explanation.

Thanks in advance.
 

Hi ​@dpi 

I have created a support ticket for this

Hi ​@dpi 
 
After further investigation, I received the following from the product team, which could help trim down the size of the repository. Please note that this will result in only the latest version of the project in the new repository.
 
1. Backup the repository database
2. Open the project and export it to XML
3. Close the project
4. Create a new repository
5. Run the following queries against either the new or the old repository.
Important: replace OldRepository with the correct old repository name and NewRepository with the new repository name

--Copy environment setup
INSERT INTO [NewRepository].[dbo].[Environments]
           ([EnvironmentId]
           ,[Name]
           ,[Server]
           ,[RemotePort]
           ,[LocalPort]
           ,[IsLocal]
           ,[UseSSISFolder]
           ,[SeqNo]
           ,[SecurityProperties]
           ,[AdditionalSettings])
SELECT [EnvironmentId]
      ,[Name]
      ,[Server]
      ,[RemotePort]
      ,[LocalPort]
      ,[IsLocal]
      ,[UseSSISFolder]
      ,[SeqNo]
      ,[SecurityProperties]
      ,[AdditionalSettings]
  FROM [OldRepository].[dbo].[Environments]
GO
--Copy global databases
INSERT INTO [NewRepository].[dbo].[GlobalDatabases]
           ([GlobalDatabaseId]
           ,[Name]
           ,[DatabaseType]
           ,[Properties])
SELECT [GlobalDatabaseId]
      ,[Name]
      ,[DatabaseType]
      ,[Properties]
  FROM [OldRepository].[dbo].[GlobalDatabases]
GO

6. Then either reconfigure the TimeXtender Server user to run on the new repository or rename the new repository to the old repository name.
7. Restart the TimeXtender Server Service.

Terms and ConditionsCookie settingsAccessibility statement