Solved

Repository cleanup

  • 17 July 2023
  • 8 replies
  • 165 views

Badge +2

We're experiencing projects to open very slowly using TX 20.10.38 (we're above version 10000 of the project) 
Is there an easy way to remove old versions of a project ? We are using multi environment with global databases, and don't want to go through the export, create new repo DB and import hustle.
We're also trying to delete the logs, but deleting them from within TX seems to take forever.

icon

Best answer by rory.smith 18 July 2023, 10:36

View original

8 replies

Userlevel 5
Badge +7

Hi @peter.jensen ,

deleting execution logging is slow indeed. If you don't do it regularly it will take a long time the first time you do it. As far as I know there is not really any other way of removing old versions from your repository other than the painful export-new repo-import process.

In the new release you could clone to a new repository and execution logging is automatically truncated to 90 days. If you are expecting to be able to hold out until you migrate that might be better than going to the trouble of creating a new repository.

I think there were some scripts floating around a long time ago, but I would not want to experiment like that in a production system.

Badge +2

Hi @rory.smith ,
thanks for the reply.
We have the issue in the dev/tst environment.  Currently the Repository Azure SQL DB is using 100% resources and we can’t even open a project anymore.
 

I think we’ll have to follow the guidelines on the portal and upgrade the Azure SQL DB  (any advice which settings should be used ?)

Badge +1

Because of the low costs I’ve been running the DTU service-tier as well at clients, but I’ve set it to 50. You could upscale the DTU’s to that or higher. I think you’ll get the best results with service-tier Provisioned with 2 cores though, but that also incurs higher costs.

Userlevel 5
Badge +7

Hi @peter.jensen ,

I typically deal with larger projects and use 2 vCore databases. If you go from 20 to 50 DTU you should see speed-up, whether that is enough should be analysed.

Note that you could also temporarily scale up to do large maintenance like execution log deletion and scale down again aftewards.

As you are likely only working in dev/test during office hours, you can also scale up for those hours and scale down after as long as you avoid any long-running task during your scaling window.

 

 

Badge +2

Hi @rory.smith , @rogier.helmus ,
thanks both for your feedback.
We’re going to upgrade to 50 DTU’s and evaluate performance for the next few days.

Userlevel 2
Badge +1

@peter.jensen There is an option under tools, to shrink repository DB to improve performance. Please try it if you haven't already. 

 

 

Badge +1

@harishkm In what, or since which release(s) is that option available? I don’t see it in 20.10.40 and @peter.jensen  is on 20.10.38.

Userlevel 6
Badge +5

Hi @rogier.helmus 

The feature is not available to everyone as it was newer officially released. It is supposed to remove all saves that had no changes.

So instead of creating a new version of all settings every time a change is saved, it would only be for actual changes. This would then decrease the size of the repository.

I can’t say why it is not officially released, maybe some unresolved bug or a change of focus.

Still I would not see it as a absolute solution to this issue as it would maybe remove a ¼ of the data, which while being some change still often made no real speed increases.

Reply