How to Build an Efficient Request Process for SQL Server DBAs

By: Jeffrey Yao | Comments (2) | Related: More > Professional Development Skills Development

Problem

As a DBA, I am frequently asked to help out in various things; from creating a login account for a new employee, refreshing a dev environment using production data, checking why a user cannot access a database to troubleshooting a performance issue. During these tasks, I often find communication is not efficient and we usually need quite a few emails and phone calls back and forth, especially when I have unclear requests and therefore a lot of wasted time. Is there any way that we can have an efficient way to communicate when asking for DBA help?

Solution

In a big company with complex environments (many applications / websites / teams / SQL Server instances), it is sometimes a challenge for a DBA to quickly understand a user's request. In this solution, we will use examples to indicate DO's and DON'Ts. The goal is to promote an efficient communication culture that will help DBAs quickly provide a solution.

We will use a few examples to illustrate typical issues that can slow down a DBA's resolution response.

Incomplete Information in Communication

This is a common deficiency in requests for help, there is not enough or clear information in the request for you to act. The requester has assumed that you know what s/he is talking about.

Example 1: Unable to connect to a SQL Server

I received the following email:

Hi DBAs,

I cannot connect to server [Server_X] with my account today, can you please help me out?

Thanks,
John Doe

There are a few issues here in this help solicitation email, in order of importance, they are:

John assumes that I know his account name, but this is not necessarily true, there are cases in a company where a person may have more than one account for different uses, and I may not know what account John was using. What's more, in a company there may be duplicate account names, especially when the account name format is Firstname Initial + Lastname or FirstName + Lastname Initial.
John did not include the error message he encountered.
John did not say what application and on which machine he was trying to connect to [Server_X], from the SSMS of his local computer or from a specific application hosted on a specific server?
John did not specify when he encountered the error, just now? 15 min ago? last night?

If all info was provided, I could investigate the issue immediately (without needing to get back to John for clarification) or may have an answer immediately (if the error message is provided).

Example 2: Here is an example from a developer

I received the following email:

Hi DBAs,

My query runs very slow today on our dev server, can you please take a look?

Thanks,
Jenny Doe

Here are few issues with this email, in sequence of importance, the issues are:

Which dev server instance are you referring to?
What is the query? Running against which database?
Are there any quantifying comparison estimates? Like usually it runs a few seconds, but today it took more than 1 minute?
Under what account is the query running?

A better email should have all the questions answered, so a DBA can work on the request immediately.

So, a revised email could be similar to the following:

Hi DBAs,

I am running the following query against server [XYZ\dev] in SSMS from my local computer with my regular account [Domain\Jenny.Doe]

use MyDB
select a.Name, b.Score, c.Subject
from dbo.Student a
inner join dbo.Exam b on a.StudentID = b.StudentID
inner join Class c on c.StudentID = b.StudentID and b.Subject_ID = c.Subject_ID
where b.Exam_Year='2019' and b.Exam_Term=1;

Usually, the query finishes in 1 or 2 seconds, but today it runs more than 30 seconds.

Can you please take a look?

Thanks,
Jenny Doe

2 - Lengthy Communication Resulting in Poor ROT (Return On Time)

In my daily work, I have observed inefficient communication that not only increases the time, but also reduces the work productivity because in such communication mode, you have to communicate multiple times to get the information you need.

These days, instant communication tools are commonly used, for example, we use Skype a lot. Many people who want to ask for help usually just type a greeting, like "Hi Jeffrey" and then wait for my response before continuing a request. It is no big deal, but when I get pinged by a few people within a short period of time, I find it actually increases unnecessary communication time and cost. It would be better if we can reduce the back and forth and reduce the communication hops.

This following example is pretty real, here is how a request might go using Skype:

1. John: Good morning Jeffrey
2. Me: Morning John.
3. John: Do you have some time? 
4. Me: not at this time, but give me 5 minutes, I am working on something right now.
5. John: Ok, will ping you in 5 minutes, is it OK?
6. Me: Ok

After 5 minutes …

7. John: Hi Jeffrey
8. Me: Yes John.
9. John: You have a minute now?
10.Me: yes, how can I help you?
11.John: It seems I cannot connect to my database
12.Me: Which database? on Which Server?
13.John: Server is [XYZ], database is [ABC]

After some checking…

14.Me: I do not see any login failures in the SQL Server log, so what error message do you get?
15.John: No error message, just time out message
16.Me: You are logging on from where by using what application and with what account?
17.John: I try to log on with SSMS from our new VM created yesterday using my regular domain account [domain\john.doe].
18.Me: Ok, it may be a firewall issue or VM installation not setup properly because I cannot see your connection attempt arriving at SQL Server side. You need to ask a network administrator to help you out.

You can see there are many communication hops (i.e. each time we need to wait for the other's response) totaling 18. But if John can make his request clear in his first message, I could respond and give him an answer more quickly and cut the communication hops to maybe only 2 instead of 18. If I could communicate with people in this efficient way, I could have saved a big chunk of time for both him and me and my work ROT (Return On Time) would be much higher.

How about just put the greeting and the question/request all at once, like the following?

1. John: Hi Jeffrey, good morning! My account [domain\john.doe] seems unable to connect to SQL Server [XYZ], it simply gives out a timeout error whenever I try to connect to it, can you please take a look? Thanks
2. Me: I will look into this and get right back to you.

This way, even when I have multiple requests, I can read the message and understand what is being asked.

3 - Low Quality Content in Communication

In this category, there are two typical cases.

The first case is that we may get an email asking for help, but there are grammar mistakes, typos or even worse, missing some critical words, like 'no', 'not', or 'never', and this causes confusion and mis-understanding. It definitely does not help and may waste your time or what you do is not what they really wanted.

The second case is that I see people communicate as follows:

Hi DBAs,

I cannot access my [XYZ] report, can you please take a look? Here is a screenshot.

Thanks,
John Doe

The issue with this email is that they did not provide the exact web link, so I cannot copy and paste to a browser to verify. I might be able to figure it out, but it would save me a huge amount of time if they provided a direct link in the email.

I also have people send me a screen snapshot of a slow query and ask me to check it. If it is short, I could retype the query, but if is long I would need to request the actual query.

The solution is to have the users provide something that a DBA can copy and paste easily for verification and recreating the issue. A picture is good, but providing something people can use immediately is better.

Summary

In this tip, I listed three common inefficient communication types and some examples. The solution is pretty simple, we need to avoid such communications so we can quickly resolve issues.

As a DBA, our value is presented by our service quality and quantity, and we need our stakeholders to "help us to help them better". To achieve this goal, a good communication culture for soliciting help from the DBA should be cultivated to maximize the return on time (ROT) on both sides. Actually, a high ROT will not only reduce burnout, but also improve our office life so at the end of a day we don't feel like "I am busy all day, but I still have a long list to do".

As a DBA, think about what could be done better to streamline the request process and help teach your end users how to make efficient request so you can quickly resolve their issues.

Next Steps

Please share your own experience and examples about inefficient help requests and together we can relay our messages to our stakeholders and with quality communication, we can provide better and more efficient service to our "customers". This will benefit everyone in the communication chain, and also our companies.

Online you may find some other interesting tips about asking for help, as listed below:

About the author

Jeffrey Yao is a senior SQL Server consultant, striving to automate DBA work as much as possible to have more time for family, life and more automation.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips