September 6, 2014 at 11:16 am
Comments posted to this topic are about the item The Real Scary DBAs
September 6, 2014 at 4:34 pm
Oh, you've hit a real pain point for me. Rather than go into a rant about it, I'll just say I'm glad that someone finally wrote about this problem.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 8, 2014 at 2:11 am
How does this happen in the first place? I good technical interview would surely sort the wheat from the chaff.
September 8, 2014 at 2:18 am
d.lawson (9/8/2014)
How does this happen in the first place? I good technical interview would surely sort the wheat from the chaff.
Many non technical organisations need DBAs but have no technical staff with which to conduct an interview. DBAs can therefore be appointed largely on how well the person fits with the organisation.
I frequently talk to managers who have no understanding of the structure of the information that they are looking at on the screen.
They must literally learn how to operate the system rote.
September 8, 2014 at 4:43 am
I work for a small company that can't afford a full time specialist. Microsoft markets SQL Server as "out of the box"....no special skills needed...it's one of the advantages over Oracle. A big part of the problem is that consumers don't think they need a DBA. When they discover that they do, a current employee will just add "DBA" to their list of responsibilities. That's my observation.
September 8, 2014 at 4:49 am
The "Scary DBAs" that I have seen tend to fall into one of two categories; forced or chosen.
The first are the ones who have been pushed into accepting the responsibilities of the role, sometimes bit by bit, and I have the utmost respect for them attempting to do their bit as they often have repeatedly highlighted that it is beyond their level of knowledge and skill (but not necessarily potential ability).
The second ones are often ambitious or concerned about job security and have far less concern with regards to the damage that they can cause. I reiterate my respect for the first ones.
For the record, I am not a DBA but a developer that sometimes also feels trepidation when assigned a task that I feel needs a higher level of competence (for the task, cheeky) 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 8, 2014 at 5:04 am
There are several points being made here.
Firstly, the mindset of many a developer, especially those that learn by trial-and-error, is that the thing being built is never finished and errors raised are merely indicators that further refinements are required to be made. The discovery of SSIS and its Lego-like building system further increases the abstraction level.
Secondly, I have been in companies where there isn't a DBA per se — often because he/she left and no one with DBA-experience was hired to replace them. Instead, one of the developers who showed an interest was pushed into the role of the previous DBA. I blame this mostly on management, who probably think that all techies are interchangeable. He probably would have been made sysadmin had it been that role that had become vacant. I blame it on management partly because there was no support given but mostly because there was no mediumterm to longterm plan for such positions. If there had been a mentoring system in place, then there would have been a junior DBA being supervised by a senior DBA and the loss of the senior DBA would not have been so tragic. The junior DBA would have known what he didn't know, as against the developer who didn't know what he didn't know. The junior DBA could have pleaded his case to management for trainining in certain areas. Management could also have allocated more time to projects to allow the junior DBA to get his house in order.
The final point is about understanding what goes on in the background. Current work-practices in the First World do not encourage the understanding of what is, for many managers, esoteric theory. If you want to learn it, fine, but do it on your time. Hence many managers are content that their DBAs can use SSMS to make backups and restores and care less whether their DBAs understand how the transaction log works or what an LSN is. DBAs, like other employees, are kept busy with tasks from their managers and if the day-to-day stuff works, well then, there isn't a problem. Never mind that it isn't documented, as flaky as hell or, to all intents and purposes, unrecoverable in the event of a disaster. If were done properly, it would take much more time, and that wouldn't be good, would it? Scary DBAs would be a lot less scary if they were managed properly and worked within system where best practices were the norm and resources were allocated to allow best practices to be followed. That being said, a DBA that doesn't want to learn how it all works is one to watch.
September 8, 2014 at 6:34 am
There's a certain class of companies, that just "Wing It". They are the "slum lords" of the IT/development world. Call it "Cowboy IT" or "Just Make It Work" development. And they get away with it because the customers don't know any better or can't afford a quality solution.
These companies don't train their employees and may discourage them from seeking training. And you would be amazed how many of these companies you deal with and have no clue of the vital data they touch and services they perform. Eventually technical debt and dysfunction will cause these companies to lapse or be acquired. By then investors and the principles have already retired to the golf course and 3.2 vacation houses.
September 8, 2014 at 6:36 am
There's that old saw: "Some are born great, some achieve greatness, and some have greatness thrust upon them." (Wasn't that Shakespeare?)
So I guess we can re-phrase it: "Some are born DBAs, some learn to be a DBA and some have DBA thrust upon their performance evaluation."
I've been in IT for a couple decades at least and fiddling with computers since the 8-bit days. I've never been a formal DBA in that it has never been part of my job title, but I've done "DBA work" for quite some time. Most of my time was in help desk and deskside support, but over the years I've always gravitated to building databases and applications to use them. I've built several LOB solutions that completely revolutionized how the companies I worked for manage their businesses. I won't say they were perfect or even "right", but I put a lot of time and effort into understanding the whys and wherefores of what I was doing instead of just copying and pasting code from a website. I've also never been afraid to look at my own work and say, "What on God's Green Earth was I thinking?" and implement a better way as I learn new techniques. But on the other hand, neither have I been afraid to use a technique that isn't necessarily "best practice" yet is one I understand well enough to use with a high degree of certainty I won't screw things up given what I'm working with. And I always have a fallback plan. That F5 key scares the crap out of me whenever something I wrote is going into production, but I figure as long as I can roll it back without losing anything, I can push it.
There are a lot of places that methodology wouldn't be acceptable - and rightly so - but those are the places where I would expect a lot of senior/junior mentoring to be happening. The situation I'm in is just little old me trying to do what is usually done by a whole team of developers and striving to do it the best I know how given there's a lot of "how" I know I don't know.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 8, 2014 at 7:28 am
I'm always a bit conflicted on topics like these because I worked in marketing with development skills, but then transitioned into the database guy for the company I work for.
How does that happen in the first place? Well, mostly because the resources needed for a good DBA is pretty high. It's cheaper to get someone in who may have that aptitude and mold them into a DBA from trial and fire. You know, the scary part.
For me, I've worked in software development for almost a decade now. I've worked with some really amazing people who fit their positions well and I've worked with some not so amazing people who I don't even know how they ended up in the position they had. Either way, no one is perfect and I don't believe that there is a qualified candidate from the start. It takes time to mold even the best candidates into the perfect or qualified candidate.
In that, I've never found databases to be extremely complex when coming from a software development standpoint. To me, it's just a different mindset and a wealth of knowledge that needs to be learned from a different technology such as SQL Server. Other than that, it's not that scary for someone like me that is not a seasoned DBA who is trusted with a high amount of valuable information to analyse, crunch and warehouse.
I'm more than sure that some of my approaches would scare someone in this crowd. But, I'm more than sure I could find something they are doing that would scare me. So, I try not to think about who is qualified or not. I just do my homework, do my job and try to do them both right. Thus far, I've been very successful at doing it without the need of a rockstar DBA.
September 8, 2014 at 8:37 am
Every business decision is about risk vs reward.
The truth is that for many small businesses the cost of a fully trained and qualified DBA is a high and the risk of curruption followed by a rollback to last night's back up is low. If that's your world (and it really is the world of a huge nuumber of small businesses) then the correct business decision is actually to take the risk and forgo the formally trained DBA.
The real scary bit is when the acidental DBA from such a small business gets ideas above their station and heads off into the bright lights of a much bigger, mission critical system.
September 8, 2014 at 8:58 am
DavidGL (9/8/2014)
How does this happen in the first place? I good technical interview would surely sort the wheat from the chaff.
I believe it is because companies too often want to cut costs, and are short sighted about things.
In my experience, a large percentage of technical folks are really good at figuring out how to do something. The issue is that we don't always know what the best practice is, and far too often aren't given sufficient time or resources to figure that out. So we build something that will do what is required, as long as everything works just how we thought. As soon as someone tosses a wrench into the equation, all bets are off.
I am not discounting those individuals who simply shouldn't be doing what they are doing. Clearly there are a lot of people who aren't qualified and never will be. There are others who could be given the chance, and that can be due to laziness on their part or something similar. But I believe the largest issue is companies not spending money to train people. Yes, there are exceptions, I worked for one company that had people attending classes probably 4-6 weeks per year. One company.
Most of us can do just about anything. The reason we go to school, attend training, apprentice at certain blue collar jobs, is to learn more about what to watch out for. The method used to learn may vary, but that basic understanding is critical.
Dave
September 8, 2014 at 9:17 am
Certainly people need some training, though I understand companies being reluctant to train people too much as the investment might not pay off if the person leaves. I'd argue you could contract and structure that between parties, but most managers and employees don't have experience or an idea of how to approach that subject.
There's also the issue with finding training. How do you train a DBA? New Horizons classes? MS certification? I think we've not done a good job overall in technology of finding a way to train people well. Or separate those that can't/don't want to learn from those that do.
September 8, 2014 at 9:39 am
Steve Jones - SSC Editor (9/8/2014)
Certainly people need some training, though I understand companies being reluctant to train people too much as the investment might not pay off if the person leaves. I'd argue you could contract and structure that between parties, but most managers and employees don't have experience or an idea of how to approach that subject.
My tone is not directed at you, Steve, but at the worn out argument we have been hearing for years...
Of
Doing
Business.
Deal with it! The argument that people might leave is, in my opinion, ridiculous. So, you want to hire a surgeon, but aren't willing to train them? You want to hire a CFO but aren't willing to train them? Companies are willing to spend money training pretty much everyone except for IT. One way around losing staff after training is to, um, pay them. Companies that treat their people well don't have a turnover problem, and in most cases, those same companies spend money on training.
There's also the issue with finding training. How do you train a DBA? New Horizons classes? MS certification? I think we've not done a good job overall in technology of finding a way to train people well. Or separate those that can't/don't want to learn from those that do.
I completely agree with you on this point. I attended SQL training at a Chicago area company where the instructor had worked with DB2 and Oracle. Not once had he so much as opened up SSMS, INCLUDING in the class! His answer for best practices on backups was to go back to the office and ask your DBA. Uh, the class members ARE the DBAs! I know someone else who attended $25k of Oracle training, but can't do anything more than add space when required.
However, I once attended a Developmentor class and was overwhelmed by how well done it was. I think I posted about it once before here. The instructor, Tim Ewald, actually taught the class in VB, C++ and Java - doing an example from scratch in each language!
There is the issue of qualified attendees, but also an issue of qualified instructors. Sometimes we get a great instructor, sometimes an acceptable instructor. Unfortunately we sometimes get someone who is a waste of space at the front of the room.
Dave
September 8, 2014 at 9:49 am
Steve Jones - SSC Editor (9/8/2014)
Certainly people need some training, though I understand companies being reluctant to train people too much as the investment might not pay off if the person leaves. I'd argue you could contract and structure that between parties, but most managers and employees don't have experience or an idea of how to approach that subject.There's also the issue with finding training. How do you train a DBA? New Horizons classes? MS certification? I think we've not done a good job overall in technology of finding a way to train people well. Or separate those that can't/don't want to learn from those that do.
That tends to be the catch-22: if you don't want to invest in someone to help build up their skills, it's hard to engender the loyalty to stick around. Sending someone to a "canned" training class can help a little, but strcturing an actual development plan that involves facetime with truly qualified individuals in the organization send a MUCH stronger messsage. That doesn't take away the individual's responsibility, but at the same time - they're not just there floundering up the old creek without a paddle.
----------------------------------------------------------------------------------
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?
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply