December 30, 2010 at 1:57 pm
I'm sure many have vibrant careers as local DBAs ( not consultants, not working for some sort of "outsourcer" / cloud organization, etc ). The cloud really hasn't kicked in yet, but I do personally see the results of Agile / .Net development where full-fledged DBAs are viewed as obstacles. They may make room for some sort of backup / DR / production support person -- especially one who can take all the weekend work but that nobody has to really listen to.
Even the traditional backup/restore/DR realm seems to be moving towards "systems teams" using 3rd party solutions ( our company is using Commvault in this manner and investigating Netapp SnapManager ). In an ideal world, the deep sql server knowledge a good DBA should have would be valued, but it seems the goal is lowest cost using the fewest, least skilled staff. If the resulting backup/DR "solution" is actually ever needed, bean counters can hope it hits the fan after the next buyout or merger and the customers will never be the wiser.
December 30, 2010 at 2:38 pm
Indianrock (12/30/2010)
I'm sure many have vibrant careers as local DBAs ( not consultants, not working for some sort of "outsourcer" / cloud organization, etc ). The cloud really hasn't kicked in yet, but I do personally see the results of Agile / .Net development where full-fledged DBAs are viewed as obstacles.
I think this comment is an issue with the viewing of DBAs/DB Developers in general. I'm not saying there aren't hard nosed "You'll not do that in MY database!" types of folks, but in general a good DB person keeps 'em all running well, and assists the front end teams.
Cloud isn't all THAT new, it's just an abstraction layer in the network, with a new catchy name. It lets you move hardware around in the back without the front ends having to care. The day Amazon puts its databases in the public cloud is when you have to actually care. Please note... public cloud.
If you have a DB person who's inexperienced and doesn't know when to speak up to support an existing development team with ideas and ways to ease their pain, then yes. You're the obstacle. If you're usually suggesting to take on work and that you can perform tasks quickly, etc etc... then the couple of times you have to put your foot down and go no, they're a lot more likely to listen and be understanding of the necessity of the software.
Even the traditional backup/restore/DR realm seems to be moving towards "systems teams" using 3rd party solutions ( our company is using Commvault in this manner and investigating Netapp SnapManager ). In an ideal world, the deep sql server knowledge a good DBA should have would be valued, but it seems the goal is lowest cost using the fewest, least skilled staff. If the resulting backup/DR "solution" is actually ever needed, bean counters can hope it hits the fan after the next buyout or merger and the customers will never be the wiser.
This is nothing new. IT is a cost. Yes, we're a cost. The business makes money, we support the business, we're a cost of doing business. I personally usually use an analogy to IT is the equivalent of a tractor on the farm. The farmer (business) still needs to tell it where it wants to go, has to feed it gasoline (cash/resources), need to do maintenance (training your staff), and still has to drive the thing around (be involved in the project requirements). You can also make it a lot more profitable by using it properly. Go joyriding, and you just waste gas.
So, yes. All businesses reduce cost. IT is the kind of cost that seems rediculously high and should be scaled back until you realize what you lost when something goes horribly wrong. Then you end up in a 'catchup' scenario. The DBA may be outsourced, may be replaced by backup software. For smaller end shops, this is a correct action. Any good DBA can script himself out of a job as long as nothing goes wrong.
For shops that load up a few softwares, get everything running, and don't need to change stuff up in sprints but in software versions in 5 year increments, this makes perfect sense, and should happen. However, as long as companies keep developing custom software, they will need DBAs/Developers to keep their databases running smoothly. Now, if the vendors would just figure that out and hire a few of us, I wouldn't have to keep putting their tragedies on boxes that could eventually determine the atom count of the sun...
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
December 30, 2010 at 2:48 pm
Indianrock (12/30/2010)
I'm sure many have vibrant careers as local DBAs ( not consultants, not working for some sort of "outsourcer" / cloud organization, etc ). The cloud really hasn't kicked in yet, but I do personally see the results of Agile / .Net development where full-fledged DBAs are viewed as obstacles. They may make room for some sort of backup / DR / production support person -- especially one who can take all the weekend work but that nobody has to really listen to.
It all depends of the "kind" of local DBA you are talking about.
If you are talking about DBA supporting a 50 Meg database that can easily run on MS-Access... they are doomed.
If you are talking about DBA supporting multi-terabyte Data Warehouse or 60K executions per second OLTP systems... they are going to be just fine.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.December 30, 2010 at 2:53 pm
Craig Farrell (12/30/2010)
IT is the kind of cost that seems rediculously high and should be scaled back until you realize what you lost when something goes horribly wrong.
I've seen those companies. I typically see them when whatever it was has gone wrong, they have no idea how or if they can recover. Then they're wiling to pay just about anything to get their business back up and running.
I'm pleased to say that one such company learnt better after the second such disaster and now has a full-time DBA there.
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
December 30, 2010 at 3:09 pm
December 30, 2010 at 4:46 pm
GilaMonster (12/30/2010)
Craig Farrell (12/30/2010)
IT is the kind of cost that seems rediculously high and should be scaled back until you realize what you lost when something goes horribly wrong.I've seen those companies. I typically see them when whatever it was has gone wrong, they have no idea how or if they can recover. Then they're wiling to pay just about anything to get their business back up and running.
I'm pleased to say that one such company learnt better after the second such disaster and now has a full-time DBA there.
I can't really complain loudly about that method of running their business, at least not from my perspective. They keep me employed. Stressed out because I tend to absorb the attitude of those working directly around me, but employed. 🙂
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
December 30, 2010 at 4:56 pm
Craig Farrell (12/30/2010)
This is nothing new. IT is a cost. Yes, we're a cost. The business makes money, we support the business, we're a cost of doing business.
I think this is one of the major mistakes companies make. They see IT and particularly their DBAs as a cost, not as an asset. In 16 odd years as a DBA I've worked for 2 companies that saw me as an asset not a cost, and a few that saw me as a cost. The former always showed the most improvement in their environment and its stability/manageability. Because they saw me as an asset, they were willing to listen to my suggestions and evaluate them without feeling threatened, even when I was putting my foot down. In one instance overtime costs dropped to about 10% of their original levels because IT (particularly me as the DBA) was hardnosed enough to enforce some unpleasant restrictions.
Your farmer doesn't see his tractor as a cost, he sees it as an asset. Only maintaining it or putting in gas is a cost, and he incurs these costs so he will get the best out of his asset. I've seen too many companies who see their DBA as a cost go for the lowest cost DBA they can get (or none), who then have to call in an expensive consultant to rescue them when things turn to custard. The real cost is how much revenue and customer confidence they lose when they are off line for 18 hours while their primary DB recovers through a 60 GB log file - Over this Christmas!
Cloud computing may give you good 24 X 7 uptime, but it still takes a good DBA to recover your system to a point in time when a change with a bug in it goes live and deletes a few million records or resets client statuses incorrectly (Oooops; "I forgot the where clause".) Also for all those performance tuning and optimisation processes, both pre and post release. Index tuning, etc,...
I also don't understand why so many companies are adding extra apps at extra cost when SQL comes with more than adequate backup etc functionality, especially now that 2008 has compression.
I think there's still a lot of future for the good local DBA, but I think a lot of companies are going to get burned before they realise they need a local DBA. It's a pity so many people will have to learn the same lesson.
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
December 30, 2010 at 5:06 pm
Leo.Miller (12/30/2010)
I think this is one of the major mistakes companies make. The former always showed the most improvement in their environment and its stability/manageability.
I've dealt with both sides of the fence, and even being in IT I see us as a cost. We're rarely an asset unless it's an IT consulting company that sells the IT itself. I'm not saying that we don't produce assets, but the IT department in itself is not one. Your cost reduction is a perfect example. They paid the cost to produce an asset (reduction in overtime). The asset will remain, even if they remove the cost. They won't get new ones and they won't get maintenance, though.
Your farmer doesn't see his tractor as a cost, he sees it as an asset. Only maintaining it or putting in gas is a cost, and he incurs these costs so he will get the best out of his asset.
Like any allegory it gets killed in the finer details. IT is a constant investments of cash, we get paid. A tractor is a purchase (I doubt many rent...) and thus an asset. I get where you're going, but no, it's not a perfect allegory.
I've seen too many companies who see their DBA as a cost go for the lowest cost DBA they can get (or none), who then have to call in an expensive consultant to rescue them when things turn to custard. The real cost is how much revenue and customer confidence they lose when they are off line for 18 hours while their primary DB recovers through a 60 GB log file - Over this Christmas!
Ayup. Can't disagree with this. I didn't say it was a wise method of doing business for larger companies. However, your local mom and pop chain would see a significant (if not detrimental) profit margin hit paying my salary for a year... and I'm not one of the gurus. They're better off paying me to come in for a week to cover the local guy who can do most of the work, just not the advanced 'oh crap' stuff.
I think there's still a lot of future for the good local DBA, but I think a lot of companies are going to get burned before they realise they need a local DBA. It's a pity so many people will have to learn the same lesson.
Someone once asked me what a DBA did. He was completely non-IT. As I started trying to explain my job, I realized that most businesses have dang near no idea WHY they want DBA's, DB Developers, or specialists when their generic dynamic SQL coding front end programmers can do what they need... which is get data out of the DB. At least until something goes all sorts of wrong, they start researching the problem, and hopefully an intelligent (or at least, aware) manager realizes that they're missing important core personnel.
I'm not sure if an awareness campaign needs to happen, or what, but it's certainly a problem.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
December 30, 2010 at 8:14 pm
Craig Farrell (12/30/2010)
Leo.Miller (12/30/2010)
I think this is one of the major mistakes companies make. The former always showed the most improvement in their environment and its stability/manageability.I've dealt with both sides of the fence, and even being in IT I see us as a cost. We're rarely an asset unless it's an IT consulting company that sells the IT itself. I'm not saying that we don't produce assets, but the IT department in itself is not one. Your cost reduction is a perfect example. They paid the cost to produce an asset (reduction in overtime). The asset will remain, even if they remove the cost. They won't get new ones and they won't get maintenance, though.
An Asset is defined as something that will provide lasting benefits into the future. A cost is something that is consumed as soon as the cost is abosrbed. In that sense, the department of IT can be either: if all you provide is short-term/immediate maintenance, then no, you're not going to be an asset, and yes, you will end up being spun off onto the pile of oblivion.
That said - IT doesn't need to remain a pure cost. The role of productivity multiplier doesn't happen without ongoing maintenance, continually working on providing long-term advancements while keeping the lights on. In most businesses of a certain size, there's viretually an unlimited amount of items to automate, speed up or integrate with something else.
On the DBA side, I would envision a lot of the maintenance going almost entirely automated in the next few years. That said - as the size of corporate data stores keeps exploding, there's going to be an increased need for folks who understand how to handle, store, and present data from huge repositories: tapping into the "extra 20%" of performance will continue to be performed by high-end specialists. So I'd see more "special purpose DBA's" and fewer folks with the title who are in charge of swapping out the tapes in the morning.
----------------------------------------------------------------------------------
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 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply