I work in a large UK company as a statistician.

In my role I have to ask a group of database administrators for key datasets. They usually tell me that data doesn't exist (when it actually does), that it will take many hours to extract it (it actually takes minutes) and I have to go through a lot of red tape to get it (which I do but to no avail).

This is an endemic problem that affects all of my colleagues. How can I build a smoother working relationship with my database administrator colleagues?

Thanks in advance for your help with my first time post!

  • 1
    This question appears to be off-topic because it is about interfacing with DBA's this is probably better asked on dba.stackexchange.com Commented Oct 3, 2014 at 15:58
  • 7
    @ReallyTiredOfThisGame ...and if you post it on dba.stackexchange, someone will say it is off-topic because it appears to about interfacing with a person and is probably better asked on workplace.stackexchange.
    – teego1967
    Commented Oct 3, 2014 at 16:24
  • An option might be to avoid them - you do make backups, right? Restore yesterday's backup to your own machine, and you get all the data you need without requiring any effort or assistance from them. Or get a periodically synched 'slave' copy under your control, one that can't disrupt or slow down daily operations since it's completely separate. For most companies their "big data" amounts to a few terabytes or even gigabytes, and thus doesn't need any expensive hardware to analyze.
    – Peteris
    Commented Oct 3, 2014 at 17:28
  • 4
    This Q is on-topic. Replace 'DBA' with any other profession - we can all think of situations in the workplace where you ask for resources and the person involved resists.
    – user8036
    Commented Oct 5, 2014 at 10:01
  • Are you sure you are going through the right channels? Maybe there is a procedure in place for these requests and simply asking them directly is not the best approach? Commented Oct 5, 2014 at 10:11

9 Answers 9


The DBA's see it as an out-of-band or ad-hoc request.

From their point of view, their job is to keep the database alive for the fixed, well-defined list of CRUD applications that use it. Anything else is "not their job" and takes them astray from what they're supposed to be doing.

This is an increasingly common problem that organizations encounter as more people start using BI (business intelligence) tools and various forms of data mining/analysis/science.

In my opinion, you have three options:

  • As others have said: Appeal to their goodwill by persuading them of the value to the organization that getting you your datasets provides. If your request is easy enough and these people are capable of adapting it is preferable.

  • Coerce cooperation through management. This is probably the simplest solution although it is stressful and unpleasant for everyone involved.

  • Create some type of application or automated way to get your datasets. This is a way to integrate your needs into a form even the most stubborn DBA can work with. The trade-off is that it is a project in itself and may be significant in scope. If you have serious requirements that go beyond an occasional query and your datasets span multiple concerns across the organization, this is what you need. This requires considerable help from people that understand the database itself AND those who understand the schema (the owners of the data).

  • Thanks for everyone's suggestions. I'll be trying them out in the workplace soon!
    – user27483
    Commented Oct 5, 2014 at 14:14

This is not a specific problem to DBAs, but in general so here is how I tend to more effectively work with people who don't orginally want to cooperate.

First, talk to them about what is on their plate right then before asking for something. From a DBA perspective, your data request may be a very low priority compared to everything else they have going. That could very well be why they put you off.

Follow their process. If they have a request process it is probably because they have too much to do and need to prioritize. Trying to short-circuit their process will make them annoyed with you. In the process however, make them aware of the criticality of the request. I will also point out that I will consider your urgent request to be more urgent if every request I get from you isn't urgent. People who cry wolf tend to get ignored.

Allow time in your own planning process to get the information and ask for it sooner rather than later. It is very annoying to have people ask for stuff that they need in the next ten minutes when you know they have known about the task for weeks.

Do what you can to help them out when you can. People respond better to people who do them favors. People respond better to people who give them public praise and, yes, the occasional flowers or chocolates haven't hurt in getting people to help me out.

Look for alternative ways to get the work done. Are there people other than the DBAs who can query the datbase? Can you get query rights so you don't have to annoy them? They may be willing if you ask as a way to reduce their workload by taking these tasks off their plate. Suggest that you can learn to do the queries and just have them review them before you run them.

If you feel as if they have a problem with you and that is why they put you off, sit down in a meeting to discuss it. Ask them what you can do to improve how you work together. Ask them how they want to work with you. Ask them how much notice they need and explain the situations where that may not be possible.

As a very last resort, you might need to talk to their boss about the lack of support and the lying. But you will make enemies this way, so it is a last resort. On the other hand if after trying hard to work with them, you can show they will not work with you, you really have no other recourse if you need to get the job done. But go to them with documentation of when you asked for things, what you were told, what the truth ended up being, how you requested an alternative way to get teh work done but got turned down, etc. You probably shoudl go to your boss and have him put a little pressure on their boss first. Start with simply asking your boss to set priorities with their boss, don't go to the complaints about lack of support until you try that first.


There are, unfortunately, only two (obvious) options at hand:

  • Ask them why they told you x but the outcome was actually y.

You told me that the run-time of S would be T but it turned out to be T/T2, can you explain to me why you thought it would take so long and maybe how we can avoid this conflict in the future?


It turned out that value V was actually available in location L, but it took me a long time to find it due to my little knowledge of the storage system, can you tell me why you thought that it wasn't available, is it perhaps just recently added?

This option is probably the better option, maybe they simply misunderstood what you were asking for or they simply forgot. However, if this doesn't really help (it keeps happening) or it results in negative attitude towards you then you might have to step up to the second option:

  • Involving your closest manager.

If there's an issue that's affecting your work in a negative way then you should bring it up to your closest manager, who decides how to tackle the problem. He/she might either come up with a more effective process for you to gather information from your co-workers or he/she might have have make your co-workers understand that it's important that you are not, repeatedly, given incorrect information when they're the experts of the matter.

This is, however, a quite complicated matter but simply asking them why things went the way they went is probably the best way to avoid some potential attitude, but like I say, if that doesn't work then involving a manger is the best way to do to reach out for a solution.


Can the DBAs give someone on your team limited access? Read-only access to get the data you need? Perhaps someone in your team may offer to be a "back-up" to your DBAs, as part of an organizational "cross-training" or "shadowing".

Just some ideas, depending on your organization's dynamics. In other words, you have to show the DBAs how you will make their jobs easier.

  • 1
    Just to note - Depending on the way the data is stored it could be that even Read-Only access has the potential to cause trouble - for example if the users craft very bad queries that cause deadlocking that could impact the live database (if indeed the queries are to a live database, and not a recent backup instance) Ideally they should set up some Business Intelligence tools, but whether thats worth the time and expense depends entirely on the frequency and diversity of the data requests
    – James S
    Commented Jul 6, 2017 at 16:33

Lets break down things you can do to minimize the friction, and hopefully sway the DBAs in helping you out in a meaningful and productive manner.

The Request itself

How you request things is arguably the most important. You should request information as soon as you know you need it (If it's something where you'll need it later, because you'll need up to date information, you should simply request that you will need whatever data at XX time) The sooner you can request this the better. (If they are prone to forget send them reminder the morning / a bit before you need the data)

You need to use their process. If they don't have a set process ask them how they would like you to make these requests. Ultimately if you aren't provided with a means of getting the data yourself then they (or someone on their behalf) needs to be responsive to fulfilling these requests.

Be specific! If you ask for "all sales data" the DBA is NOT going to be happy... If you ask for The customer's name, amount paid, item[s] purchased, and timestamp of the transaction from 10/1/2014 to now they will be far more amenable to the request. (basically make sure they know exactly what you need, vague requests can be VERY frustrating)

DBAs and Priority

DBAs work a position where there is ALWAYS more to do, and never enough time to do it. As such the typical DBA attacks problems purely by priority. What dictates that priority varies person to person, but typically it's either whatever has the most significant impact to the company (Increased income, Mitigate risk) or Whatever the person over them says is priority.

Sadly it's a near certainty that data request with no real context to it's value is going to be low priority. In the ever growing list of things that need doing the low priority list tends to be a grave yard where requests go to die.

So depending on what the priority system is (you can ask, most will just tell it like it is) you need to tackle it to make it clear the value of your request.

If the DBA just follows the chain of command you need to get their boss sold on the fact this data is important. Perhaps it's for a sales campaign that could potentially be highly lucrative, or perhaps your CEO said you need to get them to do this. Once you can say "Hey DBAs I need (Specific Request) CFO Chad wants to get a campaign going that could be good for business, when can you assist?"

You just showed the DBAs this has a monetary value to the company, and the execs want it. You just made your request more valuable and thus a higher priority! (Don't just always name drop an exec, you're not trying to drum up your requests to priority one, you're trying to show that these requests have an appropriate value and you're not just asking for the sake of asking)

You're one of us, not them

IT at large tends to be a tightly knit group. They tend to hear all the complaints with little praise and work closely "Fixing your problems". Often this results in a Us or Them mentality where you're either part of their team, or you're those annoying end users. (This is a generalization, many IT dept have a much healthier outlook than this)

You want them to feel you're as much their team as anyone else. If you need to throw a short deadline for a request to the DBAs don't say "Hey DBAs, I need X ASAP" That's something "one of them" would do. Instead say "Hey DBAs, I'm really sorry for the short notice, but the CEO just asked me to X and Y, but I need data Z to do it. Any chance you could help me out here?" This time you aren't one of "them" you're as much a victim as they are, they'll be far more amenable to trying to bail you out. (as long as this doesn't happen all the time)

Build a friendly relationship with IT. Most people just don't network around the office, Seriously networking with your support staff is a HUGE benefit. Simply put when things go to hell IT can save you from some of the most crushing mistakes, or they can let you drown in those mistakes. (not that they do so intentionally, but people are more likely to bail you out if you have a healthy working relationship)


Bribes are one of the single most effective tools to getting IT on your side. There is also no better work appropriate bribes than food! IT doesn't work in a "What's in it for me?" manner, but again if you have a good working relationship it's far more likely I'll bump you up the priority list. (Is this how it should work... probably not, but it also has it's perks)


In the Us or Them situation, people within IT might pick each other up a lunch, or say a heart felt thank you, etc. Because seriously IT is a really thankless jobs where the vast majority of users frankly dump all over IT because their preventing large scale problems are often inconvenient to individuals.

Don't be another thankless user dumping working on IT then responding with an email that just says "thanks" that's seriously the least you could do for someone who took time out of their day to help you out (even if it's their job)

When you pass them in the hall stop and say "Hey Bob, Seriously thank you for Wednesday, my boss was really riding my butt, you're a life saver" or if your company does some kind of kudos or shout out (Basically where one employee / department recognizes another) make it a point to put one out there from time to time. If IT is mostly secluded to their "cave" make it a point to drop by and thank them in person.

It IS their job to help the users, but seriously most IT depts listen to nothing but complaints, whining, and demands all day. Getting that occasional REAL thank you. (and if you're really awesome something to snack on) Really helps take the edge off their day, and if you come by and make their day a little easier, they will almost certainly return the favor.


It's a tricky problem. Some people within a company want to do as little work as possible. Some are burned out from doing meaningless crap for ungrateful jerks.

What's in it for them?

There are, in my opinion, three main things you can do.

  1. Explain why this work is important. If you're saying "Can I have the sales data for 2013" that's not nearly as important as "The CEO needs to report some figures to the board. Can we get the XYZ so that we can show investors how well we're doing."
  2. Praise them. An email to their boss, copying them in, saying "I just want to thank the team for XYZ. It really made a difference and ..."
  3. The nuclear option. Complain. Raise this with your manager and get them to talk to their manager.

Ultimately, you need to find what makes that team tick. Is it a box of chocolates to say thanks? Is it a mention in the weekly newsletter? Is it a chewing out from the boss?

  • While I agree that one should be grateful for other people's help it should not be mandatory to make a big deal out of it, a simple "Thank you" should be enough; the company is already paying them for helping you, a box of chocolate should not be necessary. I agree with 1. and .3 though, but like I mentioned in my answer: after trying to solve it on your own with the coworkers.
    – Jonast92
    Commented Oct 3, 2014 at 15:50
  • 1
    @Jonast92 while a box of chocolates isn't necessary, sometimes being the person they most like to work with, because of an occasional box of chocolates in addition to the thanks, makes things go much better. You want to stand out in a good way with the DBAs. Commented Oct 3, 2014 at 15:54
  • @Jonast92 it shouldn't be mandatory. But some people need a little extra push. Tipping at a restaurant shouldn't get you a better table, but it's often a small price to pay in the grand scheme of things. Commented Oct 3, 2014 at 15:57
  • I've found #2 to work wonders. Often times these people get zero thanks for difficult jobs. A little recognition and a proper thank you goes a long way. I have found that a specific thank you email isn't always necessary, often just including a, "oh and bob the dba was super helpful in getting this task done" in a status report kind of email is plenty. You don't even need to cc bob. Commented Oct 3, 2014 at 16:18

When you need the data from Project X (for whatever reason), you need to talk to the Manager of Project X. He can then assign a task "data export for user1108", prioritize it and so on.

Trying anything else will only cause confusion, tension and might even be illegal if they see it as an attempt to steal their data. I assume you are allowed to request it, just saying.


Disclaimer: I am assuming the role of DBAs is the same in your organization than in all of the others I know of you. Of course, it may happen that your organization has given your DBA different responsabilities.

In short: You do not understand what DBAs are for.

They keep the database servers up and running. They profile their usage (so the DBs never stop because they run of RAM or disk space), perform the DB system maintenance work (backups, partitioning) and -in some small places- solve DB related incidencies (v.g. deadlocks). Occasionally, they may help some programmer or user to simplify a query that, in its current form,

Usually they have only a slight idea of what each DB is used for, but they do not know the internal design (*) of the data. They just do not have enough time for that, and anyway programmers sheldom inform them in the changes the make.

To add to that, remember that THE DATA IN THE DATABASES DO NOT BELONG TO DBAs. It belongs to the responsable of each information system, and it is to him to who you should direct your requests.

To put an analogy, you want some data that is in a file cabinet in a storage rental facility. Asking the DBAs for it is like asking the maintenance guy of the facility to:

  • stop doing the job he is being paid for,
  • open for you the space of some other guy,
  • and then spend part of his work time trying to understand how the data is organized in the file cabinet...

Of course, it might be also in your organization is the DBA duty to provide you such data, but nobody has told them so, and treat you accordingly. Or maybe they are just overworked.

(*) They may look deeper into the data design if they find that a DB is taking up too much resources. And in that case, what they do is usually call in the programmers, demand that changes are done to the software/queries while providing some help, and nothing more.


The question that is interesting to me is why are the database administrators saying that the data is not there when it is actually there and why they are saying that it will take hours to extract the data when it actually takes minutes. And why is it that you know something that they don't?

If, for example, the answer is that you are the subject matter expert and they aren't, then the key to a smoother relationship is that they recognize you as a subject matter expert and that they give you the benefit of the doubt when you make your request for data.

If, for example, they are plain lazy, then the key is working through their management to extract the cooperation that you need.

If, for example, THEY think they are the subject matter experts, then the key is to get them to accept that they may not know as much as they think they do.

You need to find out where they come from when they say the things they do, and from your finding, you'll have a clearer idea of what you need to do to steer their cooperation into the direction you want to go.