• State Verified Answer
  • Replies 5 replies
  • Subscribers 49 subscribers
  • Views 2697 views
  • Users 0 members are here
Options

How many TMs can you safely create and manage in a single container?

Gwen Gondry

Hello all,

I read in a discussion on this forum that containers "allow you to split your TMs into several physical SQL databases" (see https://community.sdl.com/product-groups/translationproductivity/sdl-groupshare/f/groupshare-qa/6476/what-is-a-container-in-a-groupshare-context).

We're new to GroupShare and we would like to take this into account as we're about to create several dozen domain-specific TMs for a single language pair. 

Does anyone have an idea of the number/size of TMs that could be safely created and managed within each container?

By "safely" I mean :

  • limiting the risk of ending up with a corrupted db file
  • backing-up the db-files quickly and efficiently
  • optimizing look-up and update performance on our TMs
  • + any other aspect I might not be aware of... :-)

Thanks a lot!

Gwen
Rate translation
×
Suggest better translation
×
Parents
  • +1

    Hi,

    i do not think there is a limitation as such. It always depends on your organizational architecture, if you distribute TMs across multiple containers you would have better maintainability of the SQL side. The size of DB containers depends only on the amount of TUs, and not TMs.

    i.e. if you have 20 milions TU's we are talking about 150GB DB file (75 GB backup) , so you should consider it...

    I am not aware about any performance problems even i am talking about te size above. But maybe someone else here has different opinion?

    regards,
    Fana
  • 0 in reply to Frantisek Spicak

    Hi Fana and Gwen,

    Well said, Fana. Another thing to consider if you are using the free Express version of SQL Server (not recommended by SDL) is that your databases will be limited to 10GB. Once it hits this limit you will not be able to add TUs to any of the TMs in that particular container.

    Kind regards,
    Nick
  • +1 in reply to Nick Date

    Hi,

    I would also add considerations regarding SQL backup (retention) considerations:

    - if you have project / working TMs which are updated on a daily basis, you might place them in a separate container (= SQL database) which is backed up daily

    - if you have read-only / legacy / reference TMs, you might add them to a separate container for which no backups are taken as you would have the original TMX files

    etc.

    When you come into worst-case scenario and need to restore a server-based TM, you usually need to restore the whole container / DB (ideally to a separate GS server instance) and then export the affected TM, see https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0024918.

    So it might be wise to spread your TMs to several containers instead of one.

    Kind regards

    Christine
Reply
  • +1 in reply to Nick Date

    Hi,

    I would also add considerations regarding SQL backup (retention) considerations:

    - if you have project / working TMs which are updated on a daily basis, you might place them in a separate container (= SQL database) which is backed up daily

    - if you have read-only / legacy / reference TMs, you might add them to a separate container for which no backups are taken as you would have the original TMX files

    etc.

    When you come into worst-case scenario and need to restore a server-based TM, you usually need to restore the whole container / DB (ideally to a separate GS server instance) and then export the affected TM, see https://gateway.rws.com/csm?id=kb_article_view&sysparm_article=KB0024918.

    So it might be wise to spread your TMs to several containers instead of one.

    Kind regards

    Christine
Children