Welcome to my first ever T-SQL Tuesday contribution. I will do a recap in case you’ve never heard of T-SQL Tuesday before.
It’s where various members of the SQL community blog at the same time on the second Tuesday of every month.
This month’s theme is based on a book called Death March. It covers poorly planned projects which the book calls “death march software projects”. You can read more about this month’s theme here.
Based on the book mentioned, we’ve been invited this month to post about a project we worked on or were impacted by that went horribly wrong. For me two spring to mind.
First was when project management went wrong. Because it resulted in job losses, I will avoid going into detail about it. Another was a SQL Server migration which I will discuss here.
I was once involved in a hardware migration project. We had tested the SQL Server upgrade. In addition, we were told that software was fine. So, we assumed it had been tested.
However, when we performed the upgrade, we discovered that there were issues with the application.
Luckily, I was able to contact somebody who knew the application well. In fact, they were so dedicated they helped me fix the issue the day before their wedding. Due to their help, we managed to avoid an embarrassing situation.
Main reason I’m telling you this is to stress just how important it is to test and plan database migrations. In addition, thoroughly test your migrated databases against whatever applications you intend to use. In fact, I recommend you test as many features as you can beforehand.
If you are migrating to a new version of SQL Server I also recommend using the Database Migration Assistant. Because it will help you identify issues beforehand and can save you any surprises.
You can also select multiple data sources in the tool if needed. If looking to use the Database Migration Assistant to check a large estate, you might want to look at using the dmacmd.exe command line version instead. You can read more about that in detail here.
In fact, you can consolidate all the results from multiple instances together. Afterwards, you can view them in a Power BI dashboard. You can read the Microsoft way to do that in detail here.
If migrating from an older version of SQL Server I also recommend keeping the original compatibility level to begin with. Afterwards, turn on the Query Store feature in the database so that you can collect a baseline.
After collecting a baseline change the compatibility level to see if you experience any changes in performance due to the new Cardinality Estimator.
Thanks for reading my first ever T-SQL Tuesday contribution. I’m sure for this month’s theme you will read other project related horror stories as well.
Hopefully, you will learn from some of our past project issues. Of course, feel free to leave a comment.