In previous post, we discussed how we can use Liquibase to deploy changeLogs to databases. Often times, when you start implementing Liquibase, you would already have a database which is being used by the application. Though Liquibase does not depend upon the existing schema, it is still a good idea to export all of the existing schema and possibly data (to some extent) and also put that information in the version control. Also, sometimes you would like to compare databases (both schema and data, again to some extent) Continue reading “Export and compare existing databases using Liquibase”
In previous post, we saw how we can install and configure Liquibase. In this blog post, we’ll see how we can leverage Liquibase to deploy changes on the Microsoft SQL Server.
Download JDBC driver for SQL Server
For this, we first need to download the JDBC driver for the SQL Server. This can be downloaded from the Microsoft using this link. The download is available in both .exe format for Windows and .tar.gz format for Mac OS X or Linux. Continue reading “Using Liquibase to manage and deploy changes on SQL Server”
Many a times, you would need to identify the difference in database schema for two SQL databases so that you can take certain course of action. There are a lot of tools in market which can do this, but you would need to pay for them to get full difference or to use them on continuous basis. However, Microsoft Visual Studio has this functionality built-in for you and if you happen to use Visual Studio as your code development tool, this functionality is basically free. So in this scenario, it also prevents hassle of learning another tool. In this blog post, we’ll learn how to do the same using Visual Studio.
Caution – I am going to demo this Visual Studio Enterprise. I’m not sure what all sku’s it is associated with, so if you cannot repeat steps below, you might want to check that. Continue reading “Compare SQL Database Schema and deploy changes using Visual Studio”
The combination of technical and cultural processes behind databases makes automation difficult. Databases has a state associated with them, so you cannot blow them away like application code and create again from scratch without losing the data. Managing change in a way that doesn’t impact the data is very problematic. Combine that with the cultural issues, the silos, it creates a really difficult problem. There are some general best practices that you can apply to tackle a lot of this complexity, but any time you try to design the solution and get into the technicalities, a lot of time you end up implementing something very specific to a particular type of database. In this blog post, we’ll learn how to use SSDT to implement continuous integration and deployment for SQL database Schema to take some of these worries away.
I don’t do this a lot since most of the apps are now a days using Azure SQL using all the benefits it offers. So I thought it would be better to take note of all the steps done for this. If the msdb database is damaged and you do not have a backup of the msdb database (for whatsoever reasons), you can create a new msdb by using the instmsdb script. In this blog post, we’ll go through steps required for the same.
Rebuilding the msdb database using the instmsdb script will eliminate all the information stored in msdb such as jobs, alert, operators, maintenance plans, backup history, Policy-Based Management settings, Database Mail, Performance Data Warehouse, etc.