Tracking database schema changes - why and how

There are many scenarios that highlight the need for tracking changes to the database schema – security, auditing and performance issues often require that you be able to pinpoint what changed when in the database schema. An index may have been dropped, a stored procedure may have been changed, a trigger may have been added and so on, and any one of those changes, however “small”, could have huge un-intended consequences from performance degradation to loss of data integrity and more.

Why can’t we use the daily full database backups to always go back and figure out what changed when – after all the database backup does not only capture the data but it also captures the database schema? Yes, BUT:
- full database backups are in many cases only available for the last few days / weeks and you are not able to go back beyond that period;
- it takes a long time to let say restore 20 different versions of a large database and figure out what changed in the schema from one version to the other
in short, even if it is possible it is not practical.

A nifty feature in xSQL Object called “schema snapshot” addresses this issue in very elegant and practical way – it allows you to take snapshots of the database schema that:
- capture 100% of the database structure – not the data, just the schema;
- have a very small footprint thus enabling you to store them forever – the database itself could be in the tenths or hundreds of Gigabytes in size whereas the schema snapshot could be a few Kilobytes in size;
- can be compared with each other and with the live database instantly without having to restore anything – instead of taking days restoring and comparing trying to track down a change you can do that in minutes using the snapshots.

xSQL Object is free for SQL Server Express with no limitations and is also free for other editions of SQL Server as long as the number of objects in the database does not exceed certain limits that you can find here…