I was working on a demo recently and needed to show that a little monitoring can help you catch schema changes. At first I looked at SQL Audit and DDL Triggers, but then I ran across a short custom metric on the SQL Monitor Metrics site that my company, Red Gate Software, put up to help people share their custom monitoring metrics and alerts.
The metric is called Schema Modified, and it uses a really simple query. This is all is does:
SELECT DATEDIFF(ss, '1970', MAX([modify_date])) FROM [sys].[objects];
It calls this query every minute for each database on which you have it enabled. This gives you a count of the number of seconds between 1970 and the latest schema modification in your database.
Now that’s not terribly useful, but if you look for changes in this metric, then it becomes interesting. For example, in one of my tests, I got this value
If I continued to run the query, the same value was returned if nothing changed in the database. However once I added a new object, then the value changed to
That’s an increase, and my alerting was looking for changes in the value, so when this new count of seconds appeared, an alert was raised.
Using the Information
What good does it do you to know that something changed? Admittedly, this may or may not be useful. This doesn’t tell you what changed, and certainly help you determine who changed things.
However, in more than a few of my development jobs, we knew people would change things. That wasn’t the issue. Really we wanted to know that something changed, and if so, we would investigate further. Often we could easily determine who made the change, based on what it was.
This is really a trigger more for something like production, where I don’t expect changes, except when I deploy things. Any other change is cause for concern, and I might have alerts set to ping people when there’s a change. If we’re making the change, then we ignore the alert, because we’re aware of it.
If we aren’t deploying changes, then we start investigating immediately.