January 23, 2008 at 4:17 pm
So I have been passively lobbing here to have a DBA hired, or at the very least a DBA position or DBA like position created. We are not a giant company, but 1000 employees in a clinic/insurance company is not precisely tiny either.
Well I found today that the IT director sees no reason for us to need or hire a DBA.
Ok, fine, usually I consider that management has some sort of plan behind their choices, and its true more often than not here. However, this has left me flabbergasted. Really, my flabber is all gasted.
We have (checking the server list..) 34 SQL servers (not DB's, servers), and at least 2 Oracle servers that I am aware of existing. The majority of these servers are set up for vender based solutions, so I can see that these servers may not require quite the level of attention an inhouse application DB would, however, there are at the very least 3 servers which are entirely inhouse application servers (live ones, there are at least two active test ones as well).
Am I really off base thinking this number of servers would be more than enough to keep a DBA busy? That is ofcourse without even considering the plus sides of having the greater knowledge of a DBA inhouse, or even, lol, getting us developers out of the databases themselves.
This is less of a rant, and more of a reality check if you will. I was pretty sure I understood what a DBA does, and the over all need of one in such a DB server and DB reliant company, yet to have not HR, or "Management", but the IT director decide we have no use for a DBA, makes me at least wonder if I am missing something.
So anyone have any thoughts on this? Any suggestions on how to explain why a DBA would be important to have?
Thanks!
January 23, 2008 at 5:55 pm
I would hope that someone qualified to be "IT Director" would have a good idea what a DBA does and be aware of the reasons to hire or not hire a DBA. If not, maybe what you really need is an IT Director.
One of the primary duties of a DBA is to keep your data safe. Backed up, proper security on data, DR planning, and just general insurance that critcal data will not just disappear. Often, it just takes one bad incident to convince management that they really need to make sure someone is on top of that.
If is the plan for when one of your developers truncates the Customer table in the production database by accident is to post a question on SQL Server Central asking how to recover data when you don't have a backup, then you probably need a DBA. Take a look at this ongoing trainwreck thread if you think that can never happen to you:
My personal favorite:
Computer technician accidentally wipes out info on Alaska's $38 billion fund
January 24, 2008 at 12:46 am
David Lester (1/23/2008)
So anyone have any thoughts on this? Any suggestions on how to explain why a DBA would be important to have?
Thanks!
Ask management what their disaster recovery plans are. What they expect to happen (and who they expect to do what) if a hard drive fails, if one of the databases goes suspect, if a table is accidentally dropped (do the developers have sysadmin access?), ...
Michael Valentine Jones (1/23/2008)
Take a look at this ongoing trainwreck thread if you think that can never happen to you:
Oh my...... :crying: That looks like it could provide a couple weeks of amusement... :w00t:
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 24, 2008 at 7:35 am
To add to the list of questions (for mgmt):
- are you expecting the issues to be discovered by the customers and brought to our attention? Who's in charge of watching over the overal health of the server? Do we want to diffuse the bomb or pick up the pieces once it's gone off?
- who gets to make sure that security protocols are being met, that coding standards exist and are used, that database-level documentation exists and is maintained (remember - do as I say, not as I do - I also have the same issue as you). Who does the testing? Who reviews the code so that you don't even allow the previously mentioned timebomb onto the server?
- who does all of the rollouts? Is it really that smart to have the entire team have access to production servers?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 24, 2008 at 8:24 am
Thanks for the replies so far, and yes, everyone of the disasters and questions I have asked in the last year or so of management. At least I know I am thinking reasonably on this matter now.
Disaster recovery: I personally sat in on the developement of that one. Fun, if the hardware goes down the IT director and network admin are to come in and build the box, and apparently which ever developer has done the most on a given box gets to restore it. (I may not be a DBA but I personally treat the box I am resonsible for as such, backups, patches and all. That assumes that I am not missing something from lack of knowledge.)
Change Management: LOL... um, sorry, after we were live on the report/warehouse server I built (scary) for six years, I managed to finally get them to buy a test server.
Ticking bomb- Well yea, and it seems to be rather loud in my mind, though apparently I am the only one that hears it.
All other questions and answers to management: "We will talk to the IT director about this, seems like a valid point" followed by "The IT director tells us its not a problem"
Ahh well, life without challenges/danger/excitement, what fun is that?
Now to hope nothing unfixable by me happens... ever. Hmm, seems very optimistic don't it?
Anyway, thanks for confirmning that I do at least understand the DBA role, and how much we need one correctly.
January 25, 2008 at 5:28 am
One of my favorites, when someone wants to know what a DBA does:
http://www.sqlservercentral.com/articles/Administering/thevalueofadba/1806/
Joe
January 25, 2008 at 6:15 am
David,
I hate to say this, but you might want to keep your resume dusted off and well polished. If something serious happens, do you really want to be around for the fallout?
Especially if your IT Director is the type of person to look for scapegoats...
January 25, 2008 at 7:43 am
I second that - the wheelman is the usually one to get blamed, even if his boss told him to drive blindfolded over the cliff......
One last thought that usually makes the difference between you or your boss being the one who packs their stuff and goes home after the bomb went off....document. everything. Keep your own copies.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 25, 2008 at 8:33 am
Thanks all, fortunately for me, I work for a separate division in the company, and the CEO here does not trust the IT director's skills, and hence through a long political fight, I actually am in IT but don't report to IT... think of it as a get out of jail free card. (Oh, and the server has bombed multiple times over the last 7 years, they are suprisingly "relaxed" about such things, or rather, they trust that I will have everything working right again quick enough that its only a minor issue. As well, the servers I am connected to are reporting servers, the company won't halt if they are down for a short time. And of course, after each time things are slow or down, or whatnot, we have a meeting to explain what occured.
I learned the "game" of office politics here much better than any one realizes (I have been here 10 years and through 4 IT directors, and 10 developers, and 4 direct managers) I would have to make some pretty large mistakes to be fired. That at least is one "nice" thing about being in the midwest, one can find companies that are not quite so "corporate" in mentality.
This whole thing is to make sure I understand what infact should be done with all these servers, and can continue to push toward what needs to be done. Heh, the way things stand should I manage to get a DBA position opened up in the company, they would likely put me in it.
Thanks again for the replies!
January 25, 2008 at 10:41 am
My take on this is that you seem to be the one burdened for the process to work right, so you do it. Become the defacto dba. Take the time, even on your own time, to produce a quality data management environment. This will not only be a great help to your company but an even greater help to your self because when the inevitable happens you will have solid dba skills to migrate elsewhere.
January 25, 2008 at 10:52 am
...or rather, they trust that I will have everything working right again quick enough that its only a minor issue...
And it's that comment that worries me. So you are the "go to" guy when the servers bomb. What happens if you win the lottery and walk away tomorrow? What happens if the problem is so severe that you can't fix it?
It's a shame you're not in a position to do a Disaster Recovery practice run at your workplace. It'd be nice to say "We're going to pretend we lost servers in fire/flood, now someone fix it!" just to see what the IT Director and all the other developers would do. Then maybe they'd see the value in a DBA.
January 25, 2008 at 11:07 am
Again, I agree with you, and "pitched a fit" when we finished the disaster recovery "plan" and the company decided not to actually test it.
I am left wondering much of the time if the admin actually take seriously a plan for "if I leave" situations. Periodically, I will be out of the office, and something will not be quite right, there is some panic, and when I return there is discussion of having me pass on the knowledge. For the first few years they could not pick a person to learn it. Now we have the issue of staff changes get in the way. That is, I spend months teaching my back up what to do, and then the back up quits for some reason or the other. I am working on getting my 4th back up knowledgeable.
Before I started working here, it never crossed my mind that being "invaluable" to a job was a bad thing.
January 25, 2008 at 11:31 am
Given the staff changes issue, you need to start documenting what it is you're training the back up people on. Create a binder filled with details on what you do. That way, you have A) A consistant "source" of training materials if your 4th BU person leaves and B) A binder you can point people to when you're out of the office.
If they can't figure out what the binder means or how to read it, politely mention to them, "A DBA would understand what I wrote in there". @=)
It always helps to have more than one backup person if possible. I've been in situations here (while we had only 2 DBAs) where 1 of us is off for the day and the other is out to lunch or in an important meeting. Granted, we have a team pager, but still...
Maybe having your psuedoDBA tasks documented (and passed out to management) would help your case. It certainly couldn't hurt to have it for emergencies.
January 25, 2008 at 12:14 pm
Again we are on the same line of thought. With what needs to be done. I have been getting one person at a time to understand and buy in on the needs, apparently its going to take time.
-its a race between an "unfixable" problem, and getting admin to realize there are technical problems that IT currently does not have the knowledge to fix. Races are fun aren't they? -
I read once that the insurance industry is many years behind other industries when it comes to technology use... I always wondered why. :rolleyes:
On an up note... I get a unique situation... A developer who has complete freedom to build what he sees as a need, in whatever way he likes. --That is I get to do what I want to with the DB -- Hmm.. good thing I think more like a DBA than a developer, imagine the mess!!!
January 27, 2008 at 5:45 am
David Lester (1/25/2008)
Before I started working here, it never crossed my mind that being "invaluable" to a job was a bad thing.
That's one thing I learnt years ago. Becoming invaluable is something to be avoided. It means you'll be consulted on weekends, bothered on vacation and called in the middle of the night. You'll also be required to fix every major stuff up that happens.
Something that someone told me years back - If a company depends so much on one person that if that person leaves, the company falls apart, then it's a very poorly managed company.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply