January 28, 2014 at 8:58 pm
Comments posted to this topic are about the item The DBA is Dead
January 29, 2014 at 1:22 am
I'd make the point that being a DBA is a mindset as much as a set of technical skills.
Is the need for the mindset getting any less? I'd argue the need is increasing.
A lot of the up and coming database systems claim to be self-managing and require 1/2 a DBA per week to look after them. That is unmitigated rubbish. I'm looking at the amount of time that one or two of these have required to get them up and running and to keep them up and running and frankly they have been resource black holes.
Yes they will evolve to a more stable position but I still don't see them being self managing.
January 29, 2014 at 1:49 am
DBA is like an Auto Pilot now, but we owns Flight and Passengers too..
January 29, 2014 at 1:58 am
Sqlserver 7.0. Was it then that the feature was introduced to configure automatic index generation?
Nice feature in the RIGHT hands, but Microsoft either forgot to mention it or emphasise it 🙂
So some heavily hit tables ended up with a large number of indexes, which was great for read performance but when you wanted to add records as well, everything slowed, because of locking.
Hey, you saved a DBA salary and got a slow database! Fair exchange?
When everyone else says something is not their responsibility, it becomes the DBA's. When there is no DBA, people feel the difference when something goes wrong but hey think of the money you saved not the money the disaster has cost the company. Got to get your priorities right 🙂
January 29, 2014 at 2:04 am
Even if the majority of production DBS tasks can be automated etc. there will always be the rest (including problem diagnosis which cannot be fully automated). I bet the number of instances managed per DBA has increased in a similar, but I bet not parallel, curve to the increase in the number of overall instances. Additionally, there is more to a RDBMS then there was before so the skill set is ever expanding.
Also, due to the combination of improved usability, increased workloads and reduced training I bet that some DBAs now have a quality gatekeeper role added to their duties as they share the load with less able colleagues. (My guess is that the like ofJefff andGaill can provide some great examples here. I, for one, am looking forward to Jeff Morden's forthcoming book "Interviewees: How do they manage to get out of bed?" :hehe:)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 29, 2014 at 2:31 am
As long as there are developers (without DBA mind-set) creating databases out there, and I see it almost every day, there will be the need for DBAs.
I fill both roles but managers within the companies that I've worked for prefer to hand the whole job to a "lead" SQL developer. This normally ends up with a single database file with no backup strategy, missing referential integrity, throw everything in the dbo schema and very little consideration for security.
A recent case saw me presenting an architecture that included multiple schemas to a manager who immediately replied that it would be too complicated to manage security. When I mentioned database roles he stated that it would be too complicated for the developers to get their heads around.
Some time later I was called in to clean up the integrity and security of the design they made up themselves and it cost more than if they'd used a more "proper" architecture. I ended up having to redesign their database to my original design and creating views as an "interface".
The more these "DBA-less" scenarios are touted, the more managers will think they don't need DBAs when, actually, we're the first person they need.
Nigel B Coates
MCSA: SQL Server 2012
MCITP: SQL Server 2008 DBA, SQL Server 2008 Developer
MCTS: SQL Server 2008 BI
MCSA: SQL Server 2008 Core
MCPD: .NET Web Developer 4
January 29, 2014 at 2:40 am
sqlservercentral 26319 (1/29/2014)
...When I mentioned database roles he stated that it would be too complicated for the developers to get their heads around....
Sounds like they have ended up with a good DBA and inadequate developers. Or at least a poor impression of the developers. I don't mean to be funny but schemas are easy to understand in principle as is the concept of database roles. Any developer worth their salt would quickly pick up how they can be combined for authentication purposes (if they didn't already know).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 29, 2014 at 4:29 am
The same manager then handed a new project to another "lead" developer and had to call me in to fix it again.
They don't seem to learn.
(I updated my profile so my nickname has changed since my previous post).
Nigel B Coates
MCSA: SQL Server 2012
MCITP: SQL Server 2008 DBA, SQL Server 2008 Developer
MCTS: SQL Server 2008 BI
MCSA: SQL Server 2008 Core
MCPD: .NET Web Developer 4
January 29, 2014 at 6:12 am
I have a background in both SQL adn Oracle and I must say the Oracle DBA's have felt this pain much more over the years. Their setup was far more labor intensive leaving less time for the DBA to focus on providing service to customers.
"So perhaps the role of the DBA isn’t necessarily dead, it’s just moved to its new home at the datastore-as-a-service provider. "
We have been working under that model for years, long before visualization. Developers are free to build objects in development and new projects can start up in minutes on existing systems. Do they make mistakes? Absolutely, and then they call an experienced DBA for assistance.
January 29, 2014 at 6:47 am
Possibly the most important skill for a DBA is the command of T-SQL and their ability to test, debug, and optimize performances of db designs and SQL code. My experience taught me that developers typically do not possess the best skills and understanding of this. While it is true that getting a db system out of the box and up and running can be accomplished without a DBA. From there on, it depends on how good you want your system to be. Goes back to the earlier discussions of how good is good enough.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
January 29, 2014 at 7:00 am
Funny, the first thing I thought when I read the title of the editorial "The DBA is Dead" was "Long Live the DBA!" 🙂
It looks like the author had the same thing in mind.
So perhaps the role of the DBA isn’t necessarily dead, it’s just moved to its new home at the datastore-as-a-service provider. The successful DBA will understand that this new world means handling petabytes of data and billions of operations on thousands of logical databases.
In fact the last line of the article is the same as my first thought on the subject.
Long live the DBA.
It's probably safe to say the situation will be exactly the same 2 years from now...
Enjoy!
January 29, 2014 at 7:12 am
I remember that article as well. Back in year 2000 we had 4 SQL Server databases.... Today we have 50 Prod SQL Servers running over 300 databases and that will grow to 900 in the next 24 months. EVERYTHING is stored in a database anymore....
Granted our DBA tasks are easier and take less time to do things but the scope of what we manage has balloned. This company buys software all the time that requires a database. It isn't just about creating a database, tables, userids... it is managing backups, recovery, disaster recovery, making sure developers aren't doing things they shouldn't, indexes, corruption, managing server resources.. etc.
January 29, 2014 at 7:12 am
Of course the DBA isn't dead. And the cited blogger was making his point with purely anecdotal evidence.
However, his point seemed mainly that a lot of places don't bother with a proper DBA role anymore, and I would certainly agree with that.
On the other hand, I would argue that in many cases the companies using databases and not bothering with a DBA are ones that would not have bothered with in house development at all beforehand. In other words, its not so much DBA roles disappearing, but more DB use popping up at the bottom end of the ladder.
January 29, 2014 at 7:27 am
The pundits said that FORTRAN was going to put programmers out of work too. The functions of a DBA will change, just like the functions of doctors has over the years. When things stop changing, it's time to worry.
January 29, 2014 at 8:08 am
You know, when I first started learning Analysis Services (SQL 2000) and MDX, I started referring to it as a "job killer", at least as a job killer for reporting analysts like myself at the time. I felt that once the typical business user could access "the single source of truth" to build their own reports, what need would there be for me to write custom sql/reports?
I'm glad I was wrong. Information needs change, and when they do, they need a person who can extract the data in a useful format. Job security, job fulfillment.
Seems the need for DBAs will remain for the very same reason. Someone needs to stay on top of security, backups, and data integrity, regardless of the changing technological landscape or the manner in which data is retrieved.
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply