SQL SERVER – Synchronize Schema across Multiple Environment – How to Overcome Database Migration Challenge

Let us begin today’s blog post with interested story, which we all database developers go through once in a life time.

Story of Database Developer

This about a scenario – you have been out of town on vacation for one week and now you are just back to work. You learn that there is a major release schedule next week of the project which you have been working for quite a long time. There are two big challenges are presented in front of you in this kind of scenario.

1. You want to catch up on the changes made by your team in the project you have been working while you have been gone.
2. You want to prepare a deployment script for the staging server (or near “real” server, where you deploy your script to test before deploying for live server).

Now when you think about these two tasks, they look relatively simple task where you just have to collect few scripts together, but if you have ever faced this situation in your real life, trust me this is not an easy task. This task will never end if your team is large and you have to catch up on everything you missed while you were away. Now preparing the

My Personal Experience

I have personally faced this situation quite a lot. My earlier job involved traveling and I was on the road quite a few times. Every time I returned, there was a change in the code or new release and I had to refresh my database server to catch up to master server’s status. It is easy when we have to sync schema changes from master server to local server. The same tasks get difficult when we want to move the changes which we have done on our local system for staging or production server. If we miss a single script the entire deployment script could fail. For example, if you have written to alter script for any table, but there was another alter script from your co-worker which executes before you change the name of the table, your script will fail. When any script fails on a production server – there is nothing but chaos. The entire release team is under pressure to resolve the issue as it is crucial to fix the issue as soon as possible in real time.

What a Smart DBA would do?

Well, everybody can do the labor, but we DBA’s are not paid for our labor work, we are paid for our smartness. We can sit and do the manual task, but what is the fun in it. I rather prefer to do something creative while I have free time instead of just doing the task which I do not like. Synchronizing Schema across the environment is no fun job. I find it is very tedious and boring. Thankfully, there are a few tools available which can help us out in this kind of scenario.

Everytime I face any issue, I immediately Google it. From one of the similar experience, I found Embarcadero’s DB Change Manager and I quickly downloaded. It is a very powerful product and I quickly configured it. With the help of this tool, I was able to quickly detect and deploy changes from one system to another system. You can download the Embarcadero DB Change Manager and try the experiment with me as well.

I strongly encourage all of you to see the video associated with this blog post to see how Embarcadero’s change manager performs schema compare and create jobs which automatically synchronizes the database. You can download the Embarcadero DB Change Manager and try comparing schema as described in the video.

http://www.youtube.com/watch?v=VjYWS4bYTKE

Reference: Pinal Dave (https://blog.sqlauthority.com)