• State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 2813 views
  • Users 0 members are here
Options
Related

Moving Translation memories and Termbases from one SQL Server instance to new SQL Server instance

Simon Bratina

HI all,

Due to SQL server reorganization we got to the situation where we would need to move all Groupshare 2017 SR1 CU9 databases from one SQL server instance to newly created SQL Server instance.

As we got two options:

A: Move databases  between SQL instances of the same version   or  B: Move databases  between SQL instances of the different version.

we decided for the option A and the following steps:  
- stop GropuShare server and its services
- stop SQL server databases
- backup GS related databases on the old SQL Server Instance
- restore GS related databases on the new SQL Server Instance (with recreating and reconnecting user accounts needed by GS
- manually modify the different config files as per:
https://gateway.sdl.com/apex/communityknowledge?articleName=000008638 
https://gateway.sdl.com/CommunityKnowledge?articleName=000006260 
https://gateway.sdl.com/apex/communityknowledge?articleName=000006263 
- modify the path to Database location in the GropuShare Console.
- restart the Groupshare 2017 server and services and everything start working as before.

Unfortunately after modify confection strings in:

appsettings.json | 
Sdl.GroupShare.WebHooksService.exe.config | 
Sdl.LanguageResourceService.Host.exe.config | 
Sdl.TMService.Host.exe.config |
Sdl.TMService.Agent.exe.config | 
Sdl.TranslationModelService.Host.exe.config  
Sdl.TranslationModelService.Builder.exe.config 

and after updating the database location and restarting services, I wasn't able to login to the Gropushare server.  Also some 3 servces didn't restart.

 

Just show the change, the connection strings were changes from:

<add name="systemDatabase" connectionString="data source=SQL\INSTANCE1;initial catalog=SDL_GS_TMService;integrated security=True;connect timeout=30" />

to <add name="systemDatabase" connectionString="data source=SQL01\INSTANCE3,1637;initial catalog=SDL_GS_TMService;integrated security=True;connect timeout=30" />

 

Did anybody completed the GS database move from one instance to antoher just by backup/restore and modifications of .CONFIG files?

I would really like to avoid going through database migration, and user import or anything else that would take me whole day (like re-install of the server).

 

As a bonus question, did anybody do the database move between different SQL versions (i.e. SQL 2018 > SQL 2014 or newer? 

 

Thank you

Simon
Rate translation
×
Suggest better translation
×
Parents
  • 0
    Hi Simon,

    we are using "almost same" scenario in our translation landscape with one difference in setup, we have deployed 2 identical GS instances/server pairs (App+DB), where is installed same GS version. With this setup we can move containers between back and forth. We do not need edit connection strings as these are not changing within , but only "Edit each [dbo].[DatabaseServer] table in your SDLSystem and Translation Memory (TM)...." to match new SQLServer instance name as per article above.

    I hope this help even it is slightly different setup.

    Anyway, can you leave a comment here if you were able successfully move containers in your setup? It should work in principle and it is interesting idea.

    Regards,
    Fana
  • 0 in reply to Frantisek Spicak

    Hi Frantsek, 

    Thank you for your comment. 

    So our challenge was to move GroupShare databases from and old SQL server to a new SQL server with different instance name and with dedicated port.

    With the help of Anette from support and some community members, we solved the problem. 

    Editing the info in the following two tables: SDLSystem -> etm.DatabaseServer  and  SDLTMService -> dbo.DatabaseServer was one part of the solution. 

    The other was in running the setup again in maintenance mode.

    BTW, we also tested the use of SQL Aliases for moving GS databases between two SQL server with different names. 

    It turned out that it is a useful workaround when you want to move databases from one SQL server to another, while at the same time you don't want to go through the setup of Groupshare again.

    Regards, 

    Simon 
Reply
  • 0 in reply to Frantisek Spicak

    Hi Frantsek, 

    Thank you for your comment. 

    So our challenge was to move GroupShare databases from and old SQL server to a new SQL server with different instance name and with dedicated port.

    With the help of Anette from support and some community members, we solved the problem. 

    Editing the info in the following two tables: SDLSystem -> etm.DatabaseServer  and  SDLTMService -> dbo.DatabaseServer was one part of the solution. 

    The other was in running the setup again in maintenance mode.

    BTW, we also tested the use of SQL Aliases for moving GS databases between two SQL server with different names. 

    It turned out that it is a useful workaround when you want to move databases from one SQL server to another, while at the same time you don't want to go through the setup of Groupshare again.

    Regards, 

    Simon 
Children
  • 0 in reply to Simon Bratina

    We plan to do something similar with our GroupShare 2017.

    Our connectionString then would sound like this "data source=DBHOSTNAME1,12345 .." (hostname (with no instance name) comma port)

    Im curious what changes you did in the [dbo.DatabaseServer]. According papers we ought to change only the "ServerName" value to the new value which for my understading would be "DBHOSTNAME1" with no port information whatsoever. 

    I feel that the papers might not be crystal clear on that part. Do we have to also provide the port in "ServerName"?

    And what setup did you ran? The installer which is like a 1.3 GB in size?

    Is there no way to avoid the installer?
  • 0 in reply to Hendrik Meißner

    Hi 

    Huh, this has been quite some time ago and ....

    So, let me try to to answer your question:

    1. If you use standard ports on your SQL server instance, the connection string doesn't need the port. 

    2. after restoring the DB's on the new SQL server, you need to do the modification in the  (SDLSystem -> etm.DatabaseServer and SDLTMService -> dbo.DatabaseServer).

    3. We re-run the same installer version that was used to install the instance on the server (to get into maintenance mode). You should be able to find the installer files on the machine in the  C:\ProgramData\Package Cache\SDL\SDLTradosGroupShare2020. 

    My understanding is that the only way to do this correctly is to run the setup-installer. Not sure why but I guess it's because some configuration / verification is only executed during setup.

     
    As I wrote initially, we decided to do the migration of SQL server of the same version just to be on a safer side and upgrade SQL later. 

    Also, before running anything, we created  a snapshot of groupshare server VM and also of all GS related databases on the SQL server. 
    emoji