SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Assessing DB Changes

One of the things I teach in our admin course is that it's not enough to just be the gatekeeper/central point of change when it comes to being a DBA, we should be adding value:

  • Look at each change and ask ourselves 'is this obviously stupid?'. For example, we might see a case where a cursor is used when clearly a a set based update would work, or we might notice a cross join
  • Verify that it meets our coding standards (this is an easy check if you don't have any!) 
  • Compare the performance of the change with the previous code, and fixing if needed. This avoids the slow and steady entropy that can otherwise result

You'll notice that I don't put in the list verifying the change is correct - that's a QA task!

One sub bullet point I've added to 'is it stupid' recently is checking queries for unused tables. I ran across a couple instances lately of what was probably copy/paste code reuse and I was tuning the queries, realized that several tables were included that had no effect on the results. Easy to miss something when you see things like this so it definitely needs to go back for testing, but it's worth taking the deeper look right then, before you deploy.


I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.


No comments.

Leave a Comment

Please register or log in to leave a comment.