Identifying database schema changes

Filed under: Administration — Brent Ozar at 2:09 pm on Tuesday, June 10, 2008

This week, Bryan Oliver and I are doing a webcast on a topic that always drove me crazy as a DBA: comparing and synchronizing changes between SQL Servers and different databases. Man, it seemed like at least once a week, someone would ask me what had changed in a database, or they’d ask me to promote a development database up to production without giving me a list of changes.

In the webcast, I’m going to refer to a few links that help with this messy chore, and Bryan will cover an option that beats everything I’ve got. <sigh> I can’t be the rock star all the time - sometimes, I’m bringing a kazoo to Battle of the Bands.

  • MSDN primer on Data Definition Language triggers - you may have used triggers before to make things happen when rows are inserted, deleted or updated from a table. That’s great when you want to audit data being stored inside the database, but what about auditing the schema itself? Say hello to DDL triggers: they’re fired when the schema is changed, like when someone tries to drop a table.
  • MSDN Code Gallery with DDL examples - after you read the first article to understand the basics of how DDL triggers work, this article will give you real-world examples.
  • Integration between SQL Server and Visual SourceSafe - I’m linking to this only to show you that it’s out there, but be careful when you implement this. My first problem involved my servers with case-sensitive collations: if you script SQL objects to files, and then check those files into VSS, don’t expect uppercase and lowercase objects to make the round trip without problems. I had several instances where someone would create an object in uppercase, then drop it and recreate it in lowercase to match our naming conventions, and VSS wouldn’t recognize it as a different file. If you have a very simple database environment with case insensitive collation, it may work, but I would only run this from your local workstation and only in interactive mode, not as a scheduled task.
  • Performance Dashboard Reports - I’ve mentioned these before in previous webcasts because they’re a great starting point for DBAs wanting to get more information about how database servers are working. The reports include a Schema History Report that identifies recent schema changes for each database. This data doesn’t stick around forever, so you have to check each server’s reports frequently - kind of a hassle.

If this sounds interesting, swing by the Quest Pain of the Week page and sign up for the webcast called “Bring Harmony to Your Databases: Compare and Sync Your Way to a Perfect Tune.”

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>