Ok start singing ‘Drift Away’ by Dobie Gray when reading this blog. Especially repeat this verse ‘I want to get lost in your rock and roll and drift away’.

Recently, an article from Red Gate on SQL Server database drift popped up in my email box. Database drift is when a database version of the metadata in production no longer matches what is in source control.

Soooooooo here’s an article review: Checking for Database Drift using Extended Events and SQL Monitor by Phil Factor.

The article has some nice snippets to show how you can capture SQL Server database drift data using extended events. ALL my fellow DBA friends have long ago converted to using SQL Server extended events vs SQL profiler … Right?

In the article, Factor states ‘Any drift in the state of the database, from the one that was deployed, is a security issue and must be investigated’.

SQL Server database drift is a monumental problem after a database deployment ESPECIALLY if you have multiple Sysadmins, DBAs, DevOPS, QA, etc. folks able to modify database objects. Even your automated apps can push SQL Server database changes if it has sysadmin abilities. I remember so fondly tracking down SQL Server database changes buried in our deployment apps. Ugh!

The article gives lots of examples and what to exclude, include and sample code. The article also pushes integration with the Red Gate ‘SQL monitor’ tool. But you can easily use the code examples to build a custom solution for SQL Server database drift. By the time you read this, additional articles on monitoring SQL Server database drift may have been published. As Factor states ‘To complete the picture …. We’ll tackle the security and access control events in the next article.’.

It’s a thumbs up must read for this article on SQL Server database drift! Right?