SQL Server DBA - How to get a good one!

Question

I'm a lone developer. I am currently developing an application which is seeing me get way way way out of my depth when it comes to SQL DBA'ing, and have come to realise that I should hire a DBA to help me (which has full support from the company).

Problem is - who?

This SO thread sees someone hire a DBA only to realise that they will probably cause more harm then good! Also, I have just had a bad experience with a ASP.NET/C# contractor that has let us down.

So, can anyone out there on SO either...

a) Offer their services.

b) Forward me onto someone that could help.

c) Give some tips on vetting a DBA.

I know this isn't a recruitment site, so maybe some good answers for c) would be a benefit for other readers!!

BTW: The database is SQL Server 2008. I'm running into performance issues (mainly timeouts) which I think would be sorted out by some proper indexing. I would also need the DBA to provide some sort of maintenance plan, and to review how our database will deal what we intend at throwing at it in the future!

Answer 1

If you can't tell a good DBA, then you need to borrow an known expert.

One of my previous employers hired an MS consultant (I had some of his books at work!) to do their interview. Another previous employer went to one of their regular consultants to do the interviews.

If you have a MS Software Assurance license then IIRC you have some included consultancy manhours to use for this purpose.

Posting on a programming forum isn't the way to go.

Answer 2

If you need a performance tuning dba, then ask questions about tuning - find out what they have done and how much it increased performance. Dbas who can't tell you metrics on performance improvements they have made probably are not good at performance tuning.

Ask about their approach to performance tuning, you want to see how they find the poorly performing items, and what steps they take to improve and measure performance improvements. You should be hearing things like finding missing indexes, investigating partitioning, improving queries to make them saragable, refactoring the database, using Profiler, etc. If they describe their process of performance tuning without mentioning that they first measure existing performance and then make the change and measure the improved performance, do not hire.

If you use an ORM, you might want to find a dba who has worked with systems that use them. You will find many dbas are opposed to using ORMs for performance and refactoring reasons. While there is a good argument to be made for avoiding ORMs from a dba perspective, hiring a person who strongly feels they are evil will not help you get a person you can work with.

If you need them for other dba tasks as well, ask about their process for disaster recovery. Ask about how they go about determining and setting permissions on the database.

One thing that seems to be critical is developer/dba relationships. Many devs hate dbas because they don't understand that the needs of the production system outweigh their code needs. Many dbas are arrogant in enforcing their rules without explanation as to why something is a poor idea. You want someone who will be able to work with devs. Yes they will create a bottleneck at times becasue their main purpose is sometimes at odds with the main purpose of the dev, but there are ways to handle those issues without being a jerk. It is a good sign if some of their references are from devs (assuming the devs actually give good references) not just other dbas.