Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
tichick
Starting Member
1 Post |
Posted - 2002-05-07 : 09:18:49
|
Hi, I just started a new dba job at a company. The old dba is transitioning out. What are key things I should ask that might not be so obvious? He's going over db's with me and we're doing some rote tasks. I know I want to learn about backups and maintenance plans, etc, but what else?I have two weeks with him, so I'm fortunate--but after that, I'm all on my own.Thanks |
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-05-07 : 09:56:42
|
Passwords might be a good thing to ask.Often times passwords are already setup in applications etc and you hardly ever need to type them in unless you change them.Maybe future plans"problem users"Michael |
 |
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-05-07 : 14:01:55
|
"Problem users" are a REALLY GOOD idea! (thanks Mike!) I can't count the amount of time I've wasted on people who will complain no matter what you do to fix it, or will break something no matter what you do to prevent them. Knowing who to avoid is a GOOD THING! In addition to Mike's suggestions, make sure you get every last bit of documentation on the databases that they have, E-R diagrams, the works. Get copies on paper too. If there aren't any, DO NOT LET THE GUY LEAVE UNTIL YOU GET ALL OF IT! Seriously. No matter how much you go over it verbally, you'll be stuck at some point down the road, and you'll need some hard paper to figure it out. Make sure that YOU understand it too; make all the notes and annotations you need.Get "war stories" too. Not only are they entertaining, they'll tell you a lot about the kind of person this guy is. He'll give you a lot of insight into the company, the politics, stuff that's not technical but can definitely affect how you do the job. And it'll cut through a lot of bullshit if you're friendly up front and you need his advice later.This shouldn't be a problem (hopefully) but keep an ear out for any recurring "issues" with the database(s). Stuff like "Well, every once in a while we have to reformat the drives" or "This job takes 9 hours to run, and I know I can speed it up, but I haven't had time". Don't ask directly though, try to steer over to it in general conversation. It's a way for you to sniff out any possible coding or hardware issues that he may, or may not, be responsible for, but didn't correct either. If you feel you can ask him directly then do so, but keep in mind his feelings too; it can sound like you're questioning his ability.I wouldn't normally bring this up, but you don't want to inherit a raft of problems from someone, or worse, find out that they caused most or all of those problems due to incompetence. We've had a few interesting threads here on SQL Team about DBA's "with 20 years experience" who've written the worst code ever, but never allowed anyone to change it, and the new guys are stuck with backups that take 24 hours to run, etc. On the other hand, if he knows that a new piece of hardware would fix something, but he wasn't allowed to order it, you'll have some backup when you have to handle it yourself.HTH |
 |
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2002-05-07 : 19:02:59
|
Good advice, Rob.Let me just add this word of caution: Take the list of "problem users" with a grain of salt. I came into a client situation and talked to one guy who I respected his abilities and opinions and he told me about "this one guy" (a.k.a. TOG) who was a problem user. A coworker overheard this (nothing is private in cubicles...) and later pulled me aside to tell me that he knew TOG pretty well, had worked with him for a couple of years and that he was a really nice guy, once you understood his sense of humor. Sure enough, TOG turned out to be a great guy, and very open to learning a better way to do things, and a quick learner at that. It all turned out to be just a personality conflict between the two, but if I had gone in with the expectation that TOG was a problem-child, I probably would have created more of a problem.So, in short, beware of adopting someone else's expectations of people. They tend to live up (or down) to them.And as for questions to ask the outgoing DBA, try to get a feel for SOP's and any "personal" admin scripts he has for monitoring and maintenance.Also ask: "What did you always wish you could do here, but never had the chance?" - This will either tell you of headaches to expect, or it will give you really cool ideas that you might be able to sell to management just because you're the new guy.Edited by - AjarnMark on 05/07/2002 19:07:05 |
 |
|
|
|
|
|
|