It’s been a while since I last wrote a new blog, and it has been a very long time since I last wrote a fresh new “What Counts For a DBA” entry. I celebrate this with a pun title.

The last technical blog I wrote was scheduled to be published on March 19, 2021 and was part of a group of blogs I was writing about SQL Server’s Graph features. This is leading to a book that I should have been really close to finishing at this point (I have not started yet!)

March 19^th was also the day of a planned minor surgery. I was supposed to be back to working shape and continuing to learn new SQL Server features and writing more blogs a few weeks later, and pretty much back to normal in about 8 weeks. Instead, over the next month I spent less than a week at home because I was in a hospital bed due to multiple surgery complications. During those weeks in the hospital, I would listen to doctors try to figure out what was specifically wrong with me and I started remembering why I had thought about becoming a doctor when I was young. There is a problem, here are the symptoms, they are going to find the problem no matter how hard they had to look.

A certain aversion to the stuff you have to see, smell, and touch removed the medical profession from my list of possible career but not my desire to find and fix things. A long and winding path of choices led me to try out programming in college which eventually led me to stumble upon the career of a DBA/database developer. Never did I realize the job would be so similar to what a doctor does at times… (With the great exception that if something is gross in my workspace, it probably came off my lunch plate, not someone’s body…I did say probably.)

Every time a user comes to me with some malady: “Computer’s slow,” “I can’t save this account’s data,” etc., it is time to start acting like a doctor. Ask the patient where it hurts, which for SQL Server is to look at the Dynamic Management Views and other places like the Windows logs. Next, have the patient demonstrate their issue by executing the code. Like any good doctor, you don’t just give up and say, “that’s all I know to do with this customer’s data, tell them they should go elsewhere to get their business.” You need to persevere to a level far beyond your basic limits and find the problem. This is made so much easier since the Internet now has all the documentation you would ever need at your fingertips. Previously we had stacks of books like Gray’s Anatomy to dig through, some that came with the server, others we bought.

The hardest part of diagnosing your systems issue is knowing when you are out of your league. Sometimes you execute a bit of code like:

Or you execute:

Each statement can produce a plethora of errors (okay, BARKUP has far fewer errors possible, but still more than 1 error message could be output!), any of which you may not actually know the meaning of. What you do next is key. Do you patiently sort through the possibilities, hunting and searching, trying things, or do you immediately call for help?

If you can’t solve a problem easily, what comes next is most interesting. I often find myself working long hours hunting for a solution. While  I don’t advocate spending all your personal time working to try to solve a work problem, sometimes it does end up eating at me if I can’t solve an issue and I spend days and nights trying to find the solution. I have worked many nights trying to solve some little issue because I knew I could do it. Usually I was correct… usually.

Complicating matters, almost every single problem you encounter will be something that is essentially your fault (or a coworker/consultant’s fault) that has a definite solution, but sometimes it can be an actual bug in SQL Server. There are few bugs in SQL Server that you might encounter with rare frequency, but when you hit one, it can reduce your hair supply.

But giving up? Everyone needs to know their own limits. But I can tell you from experience, persevering and finding a solution for the health of your patient…human, animal, or computer…is worth every second.