Reorganization of TB starts many hours after initiating in MultiTerm Desktop

Question

We have noticed that when we reorganize one of our server-based TBs which is quite big with almost 280,000 entries and 32 languages, the process itself seems to start many hours after initiating the reorganization in MultiTerm. 
 My MultiTerm log says this: 
 INFO [2021-09-06 11:47:16,205] ActionService - Start#Id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx#Name=MultiTerm.Studio.AdministratorReorganiseAction#ProcessName=MultiTerm#PhysicalMemorySize=190840832#VirtualMemorySize=151494656#ThreadCount=32#HandleCount=1523#GdiHandleCount=531#UserHandleCount=307#TotalProcessorTime=00:01:33.4687500 
 Today the reorganization finished with the following report: 
 
 According to this the reorganization actually started 21 hours after I initiated it in MultiTerm. 
 Is this caused by the TB being so large? Or is there something we could do to speed up the process?

Lydia Simplicio · Answer

Hello @ Luciano 
 I don't have anything of this sort of size to event try to replicate with, but with a large TB then it will take time. 
 It appears the processing time was just 1.5 hours, the majority of the time (Beginn/Ende) will be from the data being read, before attempting to reorganise. 
 If you have the TB stored on a remote location, It's probably best to save it locally, which should speed things up- or perhaps run it overnight if you can. 
 You said 
 Luciano said: the reorganization actually started 21 hours after I initiated it in MultiTerm. 
 am I missing something here- 
 The start time (today) was at 09.01 and ended today at 15.56

Trados Studio > 3. MultiTerm

Reorganization of TB starts many hours after initiating in MultiTerm Desktop