More of my “What Counts for a DBA” posts at Simple-Talk and SQL Server Central

In this long running series of posts that I have been working on for many years, I have discussed a lot of attributes that a DBA should have. But today, I hit upon the most important of them all: focus.

Recently, a person whom I know all too well was working on a script to drop and recreate a database from a local server as I was working through some issue in recreating a database from source control. This person ran the script, it dropped the database, and… um… well.

Wrong server

Thankfully, it was not a production database, and it was relatively easily restored (easily, but not something this person could do without contacting people outside of his team), but that did not make me feel any better. Not so thankfully, this person was me.

It was the first time I ever actually dropped a database on accident, but certainly not the first time I have done something on the wrong server (it has never been a common occurrence, but I have been a database professional for like, 34 years so you know there have been occasions).

In each and every case, I was not focused nearly enough for one reason or another. The worst thing I ever did was to delete data from a production table late one night when I was on call. I was tired and trying to focus. I am not even a 3 am (or 7 am) person when I am at a theme park or a conference. Unless I am very interested, early sessions have never been my thing unless there was bacon, and it better be good bacon.

Too much of a good thing can be bad

In this latest example, I actually was focused. On the wrong thing. I was troubleshooting a script that a tool had created out of order and I was trying to get things in order. Since there was nothing in my local database I wanted, I was going to delete my copy.

We have scripts that we create the database and set all of the settings that use SQLCMD commands to fetch the script. So I wrote the script and tested it. I was testing it again, trying to make sure it was safe enough that I didn’t accidentally drop a database (ironic, huh). After I removed the safeguards… I realized that I definitely need to use coloring on my SSIS instances.

This is what is so hard about being a DBA

Working with code (along with proper source control practices) you can typically delete source code from anywhere in your organization, for any reason. The worst thing that could happen is that you have to go fetch some files and things generally just work. You might have to recompile, but maybe not. It might not be super straightforward as to how to get your system running, but…you shouldn’t lose state.

Working with databases, I can do the same thing with all of the structures. I could have grabbed the structures from Source Control and recreated the whole database very quickly. But the data? That data is gone, at least from the place you deleted it.

If you have to work in multiple environments, and it is so important to be aware of where you are when you click [Execute] to run any SQL script.

Guardrails

The more guardrails you can put up the better. Not having rights to directly access different environment’s databases is a great step, though in my case this was a shared integration dev\test database.

Using coloring in tools to know which tool is which is awesome. SSMS’s Registered Server feature will let you color the windows and has for a while, as you can see here in Peter Schott’s article. Redgate’s SQL Prompt will color your tabs as well, which is a nice touch.

Summary

No matter how many guardrails are put up, you still have to not only focus on the problem you are trying to solve, but also focus on the fact that you likely have the right to access, view, and even delete a lot of data assets. So keep your focus anytime you are in a position where you have access to shared/production systems.