Hi dudes and dudettes...
I've convinced the boss that he needs a dba since the 3rd party firm providing dba services isn't doing the best job. I know lots about SQL development; however, I know very very little about being a dba.
We received a resume from a person indicating many years exp with 2000/2005/2008 as a DBA; however, outside tricky SQL Questions, I'm not sure where to go from there.
I'm looking for:
--Generic DBA type things.
--Stuff that a mid-lvl dba should know.
--Advanced stuff that is rather obscure.
If you are kind enough to respond, please preface the answer with the level of difficulty you feel it has... . Oh... and the answer too.
When hiring the person, I'd like to make an informed decision. Thanks all... I really appreciate it.
Hiring a DBA is both a major expense and a matter of trust on your part. Basically, you're handing the proverbial keys to the city to this person. If you don't have anyone in the company that knows enough to properly interview a DBA, then find someone that does. All asking a bunch of questions from the internet are going to do is show you that someone can memorize the (sometimes incorrect) answers. You won't actually know what someone will do if there's an emergency or something that isn't "in the book".
Also, have you considered doing any kind of background investigation, drug testing, etc? Like I said, you're handing the keys to the city over to this person.
And don't rely on recruiters to give you a good DBA... most recruiters can't spell DBA. ;-) You really need to get a pro in to help you find a good DBA that's going to take care of things properly. It's worth the wait and it's worth going the extra mile on.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs