April 6, 2018 at 8:10 am
roger.plowman - Thursday, April 5, 2018 8:54 AMJeff Moden - Thursday, April 5, 2018 8:26 AMroger.plowman - Thursday, April 5, 2018 7:18 AMJeff Moden - Thursday, April 5, 2018 6:58 AMI actually wouldn't want the server to do a whole lot of stuff auto-magically. Humans would have to write the code to get it to do all that and I strongly disagree with how many humans do things in SQL Server. It's a part of the reason why I don't work with Oracle anymore.I admit I'm curious what you wouldn't want SQL Server to automate.
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.
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!
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.
In all fairness that was ruled to be 100% the fault of the pedestrian which no human intervention could have prevented.
April 6, 2018 at 8:57 am
roger.plowman - Friday, April 6, 2018 8:03 AMJeff Moden - Friday, April 6, 2018 7:42 AMroger.plowman - Thursday, April 5, 2018 8:54 AMJeff Moden - Thursday, April 5, 2018 8:26 AMroger.plowman - Thursday, April 5, 2018 7:18 AMJeff Moden - Thursday, April 5, 2018 6:58 AMI actually wouldn't want the server to do a whole lot of stuff auto-magically. Humans would have to write the code to get it to do all that and I strongly disagree with how many humans do things in SQL Server. It's a part of the reason why I don't work with Oracle anymore.I admit I'm curious what you wouldn't want SQL Server to automate.
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.
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!
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". 😀
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".
Now you've hit some points that I definitely agree with. 😀 Better than that, it all infers one of my major piss-offs with the product team (and, generally, all development teams and not limiting that to just MS). A small but significant example is for "improvements" and "new functionality", like the PIVOT operator (absolutely sucks compared to what is in MS Access and they're written by the same company!) or the FORMAT function, which takes 44 times longer to execute than a good ol' fashioned CONVERT or that dumbass splitter function they came out with but they HAD to get those out there for "marketing purposes".
Your first point is also spot on. Why should the bad form of parameter sniffing ever be allowed to come into play? They absolutely need to spend some time on things like that instead of some of the flash-in-the-pan crap they've come out with and has since gone away or has been deprecated to go away or simply doesn't work correctly or with poor functionality. And totally agreed on the bad query discovery especially BEFORE it goes into production. It amazes me about some of the things they'll come out with but apparently have no time or resources to fix that which would make the product so much better. And I'd love it if they would setup an automatic fix for shrink file and do it in a very Peter Norton fashion so that it's actually useful for more than just an emergency and without causing the angst of having to defrag because of the index inversion that it currently done. Heh... don't get me started on the really bad code that does index REBUILDs and REORGs. Even Paul Randal says he wanted to fix it when he was working there but they wouldn't authorize the time.
I also agree with the "Do it right" saying... It's actually a mantra of mine. "Good enough" usually isn't and, although change is inevitable, it has become more of a rule than the exception it should be that change for the better is not.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2018 at 8:58 am
Jeff Moden - Friday, April 6, 2018 7:42 AMroger.plowman - Thursday, April 5, 2018 8:54 AMJeff Moden - Thursday, April 5, 2018 8:26 AMroger.plowman - Thursday, April 5, 2018 7:18 AMJeff Moden - Thursday, April 5, 2018 6:58 AMI actually wouldn't want the server to do a whole lot of stuff auto-magically. Humans would have to write the code to get it to do all that and I strongly disagree with how many humans do things in SQL Server. It's a part of the reason why I don't work with Oracle anymore.I admit I'm curious what you wouldn't want SQL Server to automate.
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.
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!
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.
In all fairness that was ruled to be 100% the fault of the pedestrian which no human intervention could have prevented.
Interesting. I'd not heard that. I can probably find it but do you have a link for that finding?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2018 at 9:16 am
ZZartin - Friday, April 6, 2018 8:10 AMJeff Moden - Friday, April 6, 2018 7:42 AMroger.plowman - Thursday, April 5, 2018 8:54 AMJeff Moden - Thursday, April 5, 2018 8:26 AMroger.plowman - Thursday, April 5, 2018 7:18 AMJeff Moden - Thursday, April 5, 2018 6:58 AMI actually wouldn't want the server to do a whole lot of stuff auto-magically. Humans would have to write the code to get it to do all that and I strongly disagree with how many humans do things in SQL Server. It's a part of the reason why I don't work with Oracle anymore.I admit I'm curious what you wouldn't want SQL Server to automate.
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.
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!
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.
In all fairness that was ruled to be 100% the fault of the pedestrian which no human intervention could have prevented.
Interesting. I'd not heard that. I can probably find it but do you have a link for that finding?
Ah.. okay apparently the story I originally read has been updated since I last read it and the dash cam has been released. https://www.sfchronicle.com/business/article/Exclusive-Tempe-police-chief-says-early-probe-12765481.php
April 9, 2018 at 9:10 am
roger.plowman - Friday, April 6, 2018 8:03 AMFirst, 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".
I'd settle for just reporting back WHICH column is causing the string truncation error. Surely SQL Server knows and it's just not telling me.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
April 9, 2018 at 10:29 am
I hate the title. It's a 60's era moniker that hasn't kept up with the times. Administration is a small part of being DBA and I agree it's the most vulnerable task to automation although performance tuning would be a hard one to automate, you can only throw so much hardware at the problem. I won't miss it much. I add a lot more value tuning important code, integrating systems, (and when I can, designing data systems) and troubleshooting production problems. The best thing about the job is the variety. I've found administration (permissions, logins, backups etc) generally boring and mundane but I know that's just my own bias; it's still critical work.
April 9, 2018 at 11:17 am
HighPlainsDBA - Monday, April 9, 2018 10:29 AMI hate the title. It's a 60's era moniker that hasn't kept up with the times. Administration is a small part of being DBA and I agree it's the most vulnerable task to automation although performance tuning would be a hard one to automate, you can only throw so much hardware at the problem. I won't miss it much. I add a lot more value tuning important code, integrating systems, (and when I can, designing data systems) and troubleshooting production problems. The best thing about the job is the variety. I've found administration (permissions, logins, backups etc) generally boring and mundane but I know that's just my own bias; it's still critical work.
Heh... I always thought DBA stood for "Default Blame Acceptor". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2018 at 11:49 am
Jeff Moden - Monday, April 9, 2018 11:17 AMHighPlainsDBA - Monday, April 9, 2018 10:29 AMI hate the title. It's a 60's era moniker that hasn't kept up with the times. Administration is a small part of being DBA and I agree it's the most vulnerable task to automation although performance tuning would be a hard one to automate, you can only throw so much hardware at the problem. I won't miss it much. I add a lot more value tuning important code, integrating systems, (and when I can, designing data systems) and troubleshooting production problems. The best thing about the job is the variety. I've found administration (permissions, logins, backups etc) generally boring and mundane but I know that's just my own bias; it's still critical work.Heh... I always thought DBA stood for "Default Blame Acceptor". 😀
That sounds about right! Some of us are 'stuck in middle' in that volatile ether between Application developers/Analysts and Systems Engineers.
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply