Is the DBA Title Dying?
- Jeff Moden - Thursday, April 5, 2018 6:58 AM
I admit I'm curious what you wouldn't want SQL Server to automate.
- roger.plowman - Thursday, April 5, 2018 7:18 AM
Let's start with index tuning and maintenance. If someone writes code to follow some god-awful "Best Practice", then you're toast, as I'm finding out in a now 2 year and 3 month experiment with indexes and the related maintenance. Follow that with the automatic creation of indexes or do like some idiot did to our systems before I started and automatically build column statistics on every column of every table (minus the blobs) in every database on every instance because "they don't take much room".
Let's go really deep and have SQL Server automatically rewrite code for "optimal performance" based on supposed "cost" (which the optimizer kind of does behind the scenes now) because the general population doesn't know some of the "tricks of the trade" but neither do the people writing the code rewriter.
Let's do like they do in Oracle and prevent me from doing certain things (like a variable overlay in a SELECT, as a super simple example) because it seems to violate some ACID principles even though those principles aren't being violated by the code. UPDATE/FROM is another prime example of where I don't want the system to forbid me to do something when I know how and why something needs to be done that might violate some other god-awful best practice. Oracle doesn't even have a FROM clause for its updates and it was a killer for me because it insisted that more than one row being updated due to a join was a bad thing no matter what.
Let's have totally automatic backups based on someone's idea of what they should be rather than what I actually need to do because someone might forget that they have to do backups (lordy, please don't ever let that happen. Use Ola Hallengren's good code, instead.)
SQL Server and similar tools are an imagination limited environment. If you have a limited imagination, then you'll have limited functionality in your environment. Don't limit or automate beyond my control what I need to get done. For example, when is it a good idea to never do a transaction log backup when the database is NOT a read-only database but is still in the full recovery model? For the answer to that, let me ask a question... when you do your laundry, do you wash all the cloths or just the dirty ones? 😀
We've already started down some wrong paths. For example, let's auto-magically flop between the current execution plan and the "last good" one to automatically "fix" bad parameter sniffing... instead of alerting someone that their code sucks so hard that it has its own gravitational field and that they actually do need to fix it. 😀
What would I like to see be automated? How about going back to the past when you install SSMS on a client machine, Books Online is automatically installed so that neophytes can actually press {F1} to get help without having to drive on the well paved on-ramp to the dirt road known as the "Internet" to get real syntax help quickly? How about automating the movement of pages to both logically and physically contiguous blocks in a very "Peter Norton" fashion when you do need to do a shrink file instead of the garbage "index inversion" method they currently use?
When it comes to doing things automatically, I don't mind provided that I can easily override or disable such automation because I find that the creators of such automations frequently have either a limited schedule or a limited imagination.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
I would say it's morphing rather than dying. Operational wise, the DBA is not becoming a needed position due to the fact of automation. With the rise of "the cloud", I do see a lot of these operational roles morphing into cloud architects if not more developmental roles that involve query tuning, ETL, and so forth.
The rise of data quality & data governance is also another area that DBA's are morphing into, which to me is just another operational position, but more focused on the data itself versus a focus on the data and the underlying system such as the database. These roles are lending itself to the traditional DBA to break away a siloed focus on the database and spreading that deep valuable knowledge holistically across the entire infrastructure.
While it's pretty scarce in my area to find a DBA role with the DBA title, there is certainly no shortage of data positions that DBA's can fill in my area.
-
WOW, very interesting article, Steve. It leaves me very ambivalent. I loved doing the DBA work I did at my old job, where I had to wear several different hats. When I was unemployed I interviewed for some DBA positions. Didn't get any of them, as my skills are more towards software development rather than being a DBA, hence the development job I'm in now. But the world of software development moves even faster. I joke that being a fan of the latest JavaScript framework is old 5 picoseconds ago. I'd been privately thinking of moving towards being a DBA at the end of my career.
But this article, and more important people such as Adam Machanic, Brent Ozar and yourself believing that the title and work of today's DBA is going away, has me somewhat rattled. I can definitely see it taking time to happen, and I think a lot of that will be because of HR not knowing how to grapple with new titles. Where are work now the whole process of change is very slow indeed. But in the whole scheme of things, even though where I work will be out of step with most everyone else, it will eventually reach even here.
Kindest Regards, Rod Connect with me on LinkedIn.
- Jeff Moden - Thursday, April 5, 2018 8:26 AM
A well thought out response.
However... 🙂
Many of your points revolve around the software not being smart enough to actually do the right thing. I admit having the ability to select different kinds of backups is dead useful--but it would ALSO be a great idea if it explained the differences between them AT THE TIME THE USER IS CHOOSING, such as Red Gate's SQL Monitor does with descriptions of the various kinds of statistics.
But I'm still pushing for better intelligence when it comes to SQL Server dealing with problems that normal operations bring up. After all, that's supposedly why SQL Server costs multiple thousands of dollars! Given the choice between the "Lamborghini Countach" of software or the "Porsche 959", I'll take the 959 hands down every time. 😎 The Countach is stupid powerful (emphasis on the stupid) but the 959 is smart enough to manage the things it *should* manage--without preventing the driver from cleverly insane maneuvers.
They want to charge beaucoup bucks for it? Fine, but it damn well better do it's job without me having to micromanage it!
-
Data is becoming everything. The classic DBA as such may be disappearing, but there is SO much employment in data management fields that a lot of stuff will just be done under different titles. Development is big, but development with comprehension of business methods, security, performance, hardware, etc will require the same sorts of knowledge and more.
For a little real life humor/horror, I had a system suddenly start bogging down at about the same time of night. Started going through the execution plans on a recently added SP, and hit this cost for a single statement. (Select DISTINCT with many APPLYs). Most expensive statement... ever
...
-- FORTRAN manual for Xerox Computers --
-
I think the title of DBA is less dying and more evolving. Many of the core skills will still be needed. If you haven't seen many systems in the wild you may think that most shops are well managed, maintained, and developed...you would be wrong. Anything wizard driven isn't going to be sufficient for an enterprise. You will find that most issues in our craft are people issues and not technology issues. People will neglect best practices and do the bare minimum then act shocked when things break. There will still be a person who has to support the database regardless if you call them DBA or what was on Jeff Moden's mug 🙂
I think the trend is as it has been in the past 50 years - more specialized. Sure you are expected to know more about general environment stuff but the paycheck is for specialized domain knowledge.
Personally, I like Brent's suggestion of a Data Reliability Engineer.
-
The longer you are in IT the more likely you are to recognise today's hot topic as yesteryears reheat. It's an endless cycle of centralise/decentralise, buy/build, specialise/generalise.
I see nuggets of interesting ideas amongst the repetition. It's amazing how many DBA-less systems end up with someone who may not be called a DBA but ends up doing suspiciously DBA-like things. I think some of these systems are DBA-less in specific circumstances that sounds like what you do but once bought you find that you use the tech in surprisingly many edge cases that requires a more hands on approach
-
Heh... all of this reminds me of the commercial from 4 decades ago and it was absolutely spot on, especially for this discussion... "You can change the box but it still the same ol' Ritz".
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Heh... is the DBA a dying title? Maybe the title is dying from severe misuse just as the term "Software Engineer" has been abused (most don't even know the true meaning of the word "Engineer") but there will always be the need for people with deep DBA skills and understanding so that people driving requests like in the following post can be both educated and contained so that they don't actually blow stuff out of the water.
https://www.sqlservercentral.com/Forums/1930425/taking-very-long-time-to-execute#bm1930585
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - David.Poole - Thursday, April 5, 2018 12:17 PM
Wow. I've only been in the industry 10 years or so, but you put into words what I have been observing in general. I've been to at least just one cycle of that centralize/decentralize, buy/build, specialize/generalize in my career.
Sometimes you wonder if they will ever make up their mind. I mean that is what I'm seeing in management and makes me wonder is everything just a cycle of what's fashionable? If so, one needs to prepare to just dance to the music of whatever is playing :blink:
- dennylou56 - Wednesday, April 4, 2018 7:31 PM
This is actually a pretty practical advice and insight. It must mean something coming from someone who's at least been that long in the business. Wish you more success in your career!
-
I am actually in the process of changing careers. I am so glad that I have been in the technology business for over 35 years. I had my own business for 7 years. I have been a database administrator for the last 18 years. I have decided to be a writer. I am ready to publish my first book in July. I am not writing about the technology I have been a part of so long, instead I am doing a biography that has not been written yet. It's been a great business, but I am ready for something a little more low key that I can do at my own pace.
- roger.plowman - Thursday, April 5, 2018 8:54 AM
In the same vein as my original response, what doesn't it do that causes you to micromanage it?
To continue the vehicular analogy, neither of the two vehicles will do well in the snow or on a poorly maintained dirt road and you certainly couldn't haul lumber to build something or would even consider using either to haul the not-so-infrequent load of dirt or manure. 😀 It used to be that things like pickup trucks were pretty basic and fairly inexpensive and would handle all of that. Now, they're not so inexpensive. They have automatic transmissions, creature comforts in the cab including heated seats, very nice looking seats and carpet, an array of electronics that will give me instructions on how to get to a destination, allow me to make hands-free phone calls, voice command, electronically display when I need to change oil, what my fuel mileage is, and even has a backup camera. It also has a special suspension to handle the potholes and bumps I may encounter and push-button-easy 4 wheel drive to handle the snow and the dirt roads. The truck bed has a special lining so that you can handle the exceptional loads without damaging the underlying metal, and so much more. And it looks good inside and out. I'd have no qualms about attending formal events driving it instead of some fancy car. The truck even has a special towing package where, if what I'm towing has electric brakes, I can configure it so it will put the brakes on the trailer earlier than it will for the truck when I first press the brake peddle (it's a standard feature now for "just in case you ever want to do it" but it adds to the expense).
Because of all that, the damned things are bloody well expensive now! They cost more than my first house and that's just for a "standard" truck! I could have bought it with the automatic "down looking" mirrors when I shift to reverse and a whole bunch of other goodies but then that would be an extra expense and there would be times where I don't want the mirrors to look down when I'm backing up.
And, yet, with all of that, I still have to change the oil, have it lubed, add air to the tires, put the right kind of fuel in it, and change the damned wiper blades. Even with the rear camera, I still have to manually back up to and align the trailer hitch with the trailer and if the rear camera is covered with road dirt, I have to use the mirrors until I can clean it.
Let's also talk about self driving cars. If they get into an accident, they're easy (if not expensive) to replace and if they hit another vehicle or an inanimate object, so are those. Recently, it was on the news that one of the damned things killed a pedestrian and they can't be replaced. A little micromanagement by the occupants of the vehicle would have gone a long way.
I look at SQL Server the same way. Yes... it's expensive but wow! The things it can do in the right hands (and you can drive it n the "snow"!!! :D). And I can "tow" just about any "trailer" (add-on) with it because it's built with that in mind. All you have to do is change the oil, add the right fuel, keep good tires on it, and watch where you're going, etc. If you need a bigger engine, it'll cost extra money just like it would in a vehicle except it's a whole lot easier to do. It won't hit "pedestrians" unless you take your hands off the wheel. But if I want it to hit an inanimate object for some reason or drive down a road not so well travelled, I don't want it to tell me "I'm sorry, Jeff. I can't do that". 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - Jeff Moden - Friday, April 6, 2018 7:42 AM
First, how about not mysteriously taking 6 hours for a query that used to respond in under a second--with no changes to the query or the number of records? How about intelligently managing empty space so the database doesn't grow unnecessarily--or the log file ballooning from some rogue transaction and staying that ludicrous size when the transaction is done? How about it keeping an eye on its operating environment so it can establish its own baselines and figure out one-time anomalies vs. a new baseline of operation? How about figuring out when a query is suddenly behaving unacceptably?
How about a better (read helpful) error message system for SSIS? How about KISS? Yes, there are a lot of moving parts you absolutely must have but SQL Server should be able to guide the accidental DBA and offer coherent explanations of options--and do it without crippling those who need to commit deliberate design insanity.
Is any of that easy for the creators of SQL Server? Hell no! But that's why SQL Server costs so much per unit. So they have the time and resources to raise the bar on the triune of capability to "do it right".
Viewing 15 posts - 16 through 30 (of 37 total)
You must be logged in to reply to this topic. Login to reply