4 Attitudes I Wish I Had Earlier as a DBA

I was tagged by Mike Walsh (blog | twitter) in his post 4 Attitudes I Wish I Had Earlier As a DBA.

I Don’t Have to Do It Alone

I’ve always worked hard in my IT career to be knowledgeable in my field. I don’t like not knowing how to do something, and I’ll spend the time and research to figure out how to make something work or how to fix a problem. Early on in my career, whenever my team would encounter an issue, I took it as a personal challenge to solve every issue. At first this sounds great. Brian is being a real go-getter. But there’s a catch.

It hurts the team. When one person is solving all the problems, especially when that one person isn’t giving anyone else a chance, the rest of the team starts to become apathetic about new problems coming in. After all, Brian will solve it. This means one person, me, gets stuck with all the new problems. It destroys my work life balance. It means I don’t have a life. I get stressed out. I miss work. Suddenly there are problems that need solving and Brian is out. Or, two big problems hit at the same time. Brian can only work on one.

Now there’s a big problem. Since others stopped solving problems, the team isn’t prepared to solve the one Brian isn’t working on. As a result, Brian, the team, and the organization suffers. It’s one thing to be a high performer. It’s quite another to try and do it all alone. What I have learned is to be a high performer and to try and bring people along with me to also be high performers. Let’s solve the problems together, so others grow.

The Technical Solution Isn’t Always the Right Solution

This one took a long time for me to get. I like processes. I like solving technical problems. Often times I could see a technical solution to a problem, albeit a complex one. It took my last manager to get through my head this simple concept: sometimes the best solution is a people solution and not a technical one.

There isn’t a standard rule when this is true. However, when you start weighing a technical solution versus a people solution and the people solution looks less complex, it’s time to start seriously considering the people solution. This is especially true when you don’t need 100% adherence or when you have time to offer a few reminders.

People Skills Are Important

One of the reasons I received promotions early in my IT career is that I was able to talk with key business folks. I interacted well with HR when we were putting in a new software package. I could understand the PMs (probably because I was one in the USAF) and could give them estimates in their terms as well as explain variances due to issues being faced. However, I sometimes struggled with developers. Don’t all DBAs? Maybe, but most of the struggles were my own creation. Rather than asking the question, “What are you trying to solve?” and then working with the developer to find the answer, I was quick on the “No, you’re wrong,” stamp. That doesn’t do anyone any good. I have found that when I can remember to engage my people skills and not my rubber stamp, I am more effective at my job.

Remember Who Is the Boss

At the end of the day, I may feel a solution is not the best. I may not like it at all. However, unless I feel that a solution or an instruction causes me to compromise my morality or my integrity, if my management decides to go a certain direction, I’m supposed to execute. I can offer my objection to my management, but if they say, “This is the way it is,” then it’s time to stop fighting and go to it.

I knew this before becoming a DBA. After all, this is the way things work in the military. You can object, if there’s time, to your immediate chain-of-command and if that person says, “This is the way it is,” you are supposed to make the command your own. However, when I got into the civilian workplace, I somehow forgot this way of thinking. I know a few situations earlier in my career would have gone a lot better if, having voiced my objections, I hunkered down and got the work done.


Nothing earth-shattering, but hopefully it’ll help someone else.

Continuous Integration/Delivery without Testing!

Anything we can do to automate our builds and deployment should be considered. After all, the point isn’t just to write code, but to deploy working code. So what if we did the automated builds and deployed them to development or QA? No errors, so I’m good, right?

Not so fast. Go back to what Martin Fowler says about testing in continuous integration. Builds should be self-testing. For instance, simply deploying T-SQL code to a database without errors is not the end. That’s merely the beginning. At this point you know that there aren’t any obvious syntactical errors. That doesn’t mean the T-SQL code works according to specification. It doesn’t mean that a view that you didn’t drop and create is okay. After all, if you change the underlying objects, that view might not work any more. Testing the build is important. And having all the tests needed to sufficiently check out the functionality of the code is essential.

Actually, more testing should be done that just checking bits of functionality like we typically do with unit or module tests. At some point during the process you should also be testing in production-like conditions. Can you have Continuous Integration (CI) or Continuous Delivery (CD) without proper testing? No, you can’t. You can have something that looks like CI or CD, and you may even call what you have by one of those names, but you don’t have CI or CD.

The fact of that matter is that you want testing; actually, you want as much automated testing as is feasible. Speeding up the process doesn’t mean end users are suddenly okay with getting buggy code. And we as IT professionals shouldn’t be okay with that, either. We can still ship and test. We just have to commit to test. Yes, testing will add time to every build cycle. However, it’s a necessity for every build cycle if you’re doing builds right. Simply compiling the code isn’t adequate testing. It’s merely the first test of many more.

Still a Need for a SQL Server Specific Organization

If you haven’t already, please read Denise McInerney’s post about why PASS no longer stands for the Professional Association for SQL Server.

The Growth of an Organization

If you’ve been involved with PASS lately, you’ve probably seen this change coming. When I read the post, I wasn’t surprised. PASS wants to grow. One area of growth is in data analytics and there’s a lot of non-Microsoft technologies out there in that space. There are a few non-SQL Server technologies belonging to Microsoft in that space, too. Therefore, at least for me, the change was expected.

Do I think PASS will be fine? I do. I think it’ll embrace the change and it’ll grow and things will continue to expand with regards to the organization. Am I disappointed? I am.  I’m not the only one.

The Need for a SQL Server Specific Organization

I am not disappointed because the organization is growing and expanding to encompass more people. I think that’s great. I think PASS, with its new mission and expanded focus, fills a need.

I am disappointed because there will no longer be a SQL Server-specific (or even centric) organization and I think there’s a need for that. SQL Server itself continues to get bigger and there’s a lot of folks using it. Therefore, I think an organization that supports the growth of the SQL Server community is a needed one. It’s not just about job security. As an infrastructure and security architect I work with a lot of different technologies. I learn about far more. If you aren’t already doing this, you should be. Don’t get tied to one technology. With that said, if a particular technology continually makes your job easier and helps you “ship,” by all means champion it.

Going Forward

I still love Microsoft SQL Server. I love a lot of the roadmap I see going forward. Look at the feature set for SQL Server 2014, for instance. Think through how and where you could use some of those technologies. Because of this, I think SQL Server is going to continue to grow and flourish. Because of this, I’d like to see a new, SQL Server specific organization come into being. However, as Grant points out, it does need to do a better job of making itself known. What Grant expresses from his own experience is what I’ve seen as well when I step away from the formerly Professional Association for SQL Server events that I have participated in. When I spoke at code camps, for instance, few in my sessions knew about PASS. I found the same thing to be true at many developer user groups as well. In the IT auditor community, it seemed like no one had heard of PASS. So if a new organization does rise up, it needs to get its name out there. The more involvement, the more recognition, the better.

Should the organization be about the big events? I don’t think so, at least, not as a focal area. There’s a lot of opportunities at the grassroots level. I’m not just thinking about user groups and the equivalent of SQL Saturdays. I’m also thinking about code camps and non-SQL Server-specific conferences where SQL Server is still a heavily leveraged technology. I think learning, networking, and occupation growth would function better at a more organic level. But maybe that’s just me. Big conferences are great, but they shouldn’t be the focus.

In Conclusion (or, the TL;DR version):

I wish PASS well in its “new” direction. I’ll be a part of it where I fit in. I also want to see a SQL Server-specific organization be founded. I’d definitely be a part of that. Regardless of whether or not that organization comes into being, we should continue to network, continue to teach, continue to learn, and continue to work together as a community.


Guest Post on SQL Authority – Default Trace & Deleted Databases

I had the opportunity to write another guest post at SQL Authority:

Finding Out What Changed in a Deleted Database

This one covers how to determine who made changes in a database that has been deleted. This isn’t a situation where you can use the schema changes history report because there’s no database to select from in SQL Server Management Studio.

I realize that there’s a limited use for the technique. However, if someone is trying to cover a some sort of mishap (dropped the wrong table, etc.) at simply by deleting a database, this is the quickest way to find out what they did. While we can agree dropping a database is typically a worse mishap to recover from, it’s a foreseeable accident and so one could have just such an “accident” to cover up changes they were attempting to make somewhere they shouldn’t have been (like changing code in production without authorization).

One of Those Must Read Books – The Cuckoo’s Egg

The Cuckoo's EggI was reading a book about network security monitoring and it mentioned The Cuckoo’s Egg by Cliff Stoll. Stoll’s book has been around for a long time, and it’s considered a classic book with regards to information security. If you’re not familiar with it, it’s the story of a gentleman who wasn’t an IT person who happened to uncover an international hacking attempt (a large one) during the Cold War era and helped track it to its source. The technology is dated – it covers incidents during the Cold War – but the basic techniques to detect, track, and catch are not.

If you have anything to do with information technology, this is one of those books you should try and read. It’s not a slow, academic tome. It’s a well-written tale based on events. You don’t have to be a security professional to appreciate it. After all, Mr. Stoll was not; he was an astronomer. Whatever your role in IT, I hope it’ll cause you to think deeper and longer about how best to implement security mechanisms and controls in what you do. It should also give you an appreciation for how the smallest detail can tip us off to something being wrong in our systems. After all, it was a tiny accounting error that led Cliff Stoll on his quest.

Guest Editorial Live on SSC

My guest editorial is live on SQLServerCentral.com. My argument is a simple one: we don’t care about data and IT security. I don’t just mean IT folks. I mean most everybody. I include myself in this characterization. I know a few exceptions, but they are truly exceptions.

In the editorial I include links as to why I make such an assertion. The TD;DR version: despite repeated breaches, our behavior hasn’t changed. Therefore, while we say we care, what we put into practice shows that we don’t.