January 31, 2017 at 7:38 am
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 31, 2017 at 7:56 am
jasona.work - Monday, January 30, 2017 2:11 PMJeff Moden - Sunday, January 29, 2017 4:42 PMHeh... "The New DBA is a Developer". No, Sir... that's incorrect. If folks are just now coming around to the idea that DBAs need to be "Developers" of the right sort, that explains a whole lot of performance issues, corrupt disk problems, backup/restore problems, and a whole lot of other problems. As you pointed out, any DBA worth their salt has a library of things they bring with them from job to job and, as we both know, they're not just some "simple DML queries".
The trouble is that a lot of people think that a DBA needs to know PowerShell, C# script, etc., etc., in order to do the job correctly or efficiently. Good DBAs have been writing incredibly effective scripts and stored procedures long before either .Net or PowerShell were even a thought. Yes, things like PoSh have made it easier to do certain things but I'm not so sure that's actually a good thing because there are a whole lot of people out there that know how to run a PoSh script that they cribbed from the internet but have no clue what the scripts actually do. That doesn't make them DBAs (although they think they are and claim to be).... that makes them dangerous especially when they do stupid things like centralizing backups for all their servers as a single point of failure using one of the "too cool for school" PoSh scripts that all the "smart guys" rushed to write to impress everyone with their new knowledge of the next shinny object.Someone should write an article called "The New DBA actually needs to learn what a DBA does and how to do it correctly". 😉 Most of the new ones that I've interviewed in the last decade can't even get the current date and time using T-SQL
Can you tell you hit a point of aggravation for me? .😛
I think Jeff, that you're getting the wrong take-away from both the editorial and the source article. Neither (to me) seem to be preaching that DBAs need to be Developers, but instead that DBAs should take advantage of some of the tools that developers use, such as source control.
The idea (at least, what I think both were going for,) being that by using such tools, the DBA will be able to keep track of why they changed things in a script, be able to quickly go back to a previous version, etc.
Not so much stating that DBAs need (or should) jump to the latest and greatest (or not-so-greatest) "shineys" (PoSh, etc.)
Such tools won't help a bad DBA become a good DBA, that's a whole different kettle of fish.Frankly, I wouldn't mind source-controlling my various work queries I've ginned up, but where I work, such tools are forbidden on the network...
My comment was based solely on the following comment in the article:
There always seemed to be a separation between a DBA that could script something and a DBA limited to simple DML queries. The latter was much less efficient, less productive, less capable of managing a larger environment.
Perhaps it wasn't intended but it makes it sound like any DBA that can't script is 1) relegated to writing only simple queries, 2) that all DBA queries are "simple", and 3) if you don't know how to script, there's no chance of you being a good DBA "capable of managing a larger environment". Although I STRONGLY agree that knowledge of some form of scripting really helps good DBAs, it is not quintessential to the job.
My other objection (serious rant) is based precisely on what Steve called out in his response to me. I'm pretty well disgusted with the (mostly locally but also worldwide to an extent) self-appointed DBAs that have somehow fooled people into hiring them to care of the proverbial "keys to the city" for companies and making 80-130K$ USD that can only use things like Maintenance Plans or rely only on other people's work (Ola Halegren , SQL PowerShell (or whatever), 3rd party solutions like RedGate Backup, etc, ad infinitum) and, when something goes wrong there, they do things like post questions on SSC like "How do I make Ola's code do the following"? They don't even take the time to read Ola's documentation of his code.
Which brings me to my point... before people start scripting things like PowerShell to do all of their backups from a centralized system, they really need to understand what happens if those backups don't work and how many systems could be brought to a halt when log files fill up. Before you learn all of the very cool new tricks for how to do things against SQL Server using things like PowerShell, you need to learn SQL Server, first. All of these "too cool for school" tricks live up to their names in the hands of the wrong people (people that don't school themselves) and we've ended up with hundreds of thousands of DBAs that don't even qualify as skilled users. 😉
p.s. And, yeah.... I write scripts to help me as both a DBA and a Developer. Always have and so have most good DBAs. That's why I also take exception to the title of the article. It shouldn't be "The New DBA is a Developer" because most good old DBAs have known and practiced that quite literally for decades.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2017 at 12:21 pm
I loved the stack overflow cartoon https://static1.squarespace.com/static/518f5d62e4b075248d6a3f90/t/583aa5b1bebafb6551322268/1480238530975/?format=750w
These days a technical estate can be so diverse that no-one can understand it all but at the same time it is dangerous to try and operate in a silo. I feel it is important to learn basic skills outside your core specialism just so you have a common frame of reference when talking to colleagues. It makes me more flexible in the approaches I can take.
Learning a new discipline changes your mindset and stimulates the creativity that can lead to good solutions. I became a much better programmer when I learned C++ even though I never used it in anger
January 31, 2017 at 10:05 pm
Jeff Moden - Tuesday, January 31, 2017 7:56 AMjasona.work - Monday, January 30, 2017 2:11 PMJeff Moden - Sunday, January 29, 2017 4:42 PMHeh... "The New DBA is a Developer". No, Sir... that's incorrect. If folks are just now coming around to the idea that DBAs need to be "Developers" of the right sort, that explains a whole lot of performance issues, corrupt disk problems, backup/restore problems, and a whole lot of other problems. As you pointed out, any DBA worth their salt has a library of things they bring with them from job to job and, as we both know, they're not just some "simple DML queries".
The trouble is that a lot of people think that a DBA needs to know PowerShell, C# script, etc., etc., in order to do the job correctly or efficiently. Good DBAs have been writing incredibly effective scripts and stored procedures long before either .Net or PowerShell were even a thought. Yes, things like PoSh have made it easier to do certain things but I'm not so sure that's actually a good thing because there are a whole lot of people out there that know how to run a PoSh script that they cribbed from the internet but have no clue what the scripts actually do. That doesn't make them DBAs (although they think they are and claim to be).... that makes them dangerous especially when they do stupid things like centralizing backups for all their servers as a single point of failure using one of the "too cool for school" PoSh scripts that all the "smart guys" rushed to write to impress everyone with their new knowledge of the next shinny object.Someone should write an article called "The New DBA actually needs to learn what a DBA does and how to do it correctly". 😉 Most of the new ones that I've interviewed in the last decade can't even get the current date and time using T-SQL
Can you tell you hit a point of aggravation for me? .😛
I think Jeff, that you're getting the wrong take-away from both the editorial and the source article. Neither (to me) seem to be preaching that DBAs need to be Developers, but instead that DBAs should take advantage of some of the tools that developers use, such as source control.
The idea (at least, what I think both were going for,) being that by using such tools, the DBA will be able to keep track of why they changed things in a script, be able to quickly go back to a previous version, etc.
Not so much stating that DBAs need (or should) jump to the latest and greatest (or not-so-greatest) "shineys" (PoSh, etc.)
Such tools won't help a bad DBA become a good DBA, that's a whole different kettle of fish.Frankly, I wouldn't mind source-controlling my various work queries I've ginned up, but where I work, such tools are forbidden on the network...
My comment was based solely on the following comment in the article:
There always seemed to be a separation between a DBA that could script something and a DBA limited to simple DML queries. The latter was much less efficient, less productive, less capable of managing a larger environment.
Perhaps it wasn't intended but it makes it sound like any DBA that can't script is 1) relegated to writing only simple queries, 2) that all DBA queries are "simple", and 3) if you don't know how to script, there's no chance of you being a good DBA "capable of managing a larger environment". Although I STRONGLY agree that knowledge of some form of scripting really helps good DBAs, it is not quintessential to the job.My other objection (serious rant) is based precisely on what Steve called out in his response to me. I'm pretty well disgusted with the (mostly locally but also worldwide to an extent) self-appointed DBAs that have somehow fooled people into hiring them to care of the proverbial "keys to the city" for companies and making 80-130K$ USD that can only use things like Maintenance Plans or rely only on other people's work (Ola Halegren , SQL PowerShell (or whatever), 3rd party solutions like RedGate Backup, etc, ad infinitum) and, when something goes wrong there, they do things like post questions on SSC like "How do I make Ola's code do the following"? They don't even take the time to read Ola's documentation of his code.
Which brings me to my point... before people start scripting things like PowerShell to do all of their backups from a centralized system, they really need to understand what happens if those backups don't work and how many systems could be brought to a halt when log files fill up. Before you learn all of the very cool new tricks for how to do things against SQL Server using things like PowerShell, you need to learn SQL Server, first. All of these "too cool for school" tricks live up to their names in the hands of the wrong people (people that don't school themselves) and we've ended up with hundreds of thousands of DBAs that don't even qualify as skilled users. 😉
p.s. And, yeah.... I write scripts to help me as both a DBA and a Developer. Always have and so have most good DBAs. That's why I also take exception to the title of the article. It shouldn't be "The New DBA is a Developer" because most good old DBAs have known and practiced that quite literally for decades.
I think you're splitting hairs here. There are always skills and qualities of a person that balances them out as good at what they do. For example, I'm not a good DBA, but my strong development skills in other languages is likely balancing me out as a data architect at my current company. Does that mean that all data architects are made up of the same ingredients? No, everyone is different, but there are trends.
DBA's come in all shapes and sizes. I think the point here is that most are trending towards adapting more skills and more responsibilities. DBA's are not the only ones trending this way, many other positions are too.
I do believe that trend exists because more businesses see value in having someone that can also do X, Y, Z. I also do believe they are not seeing those wants as hard to find because of said trend is pushing DBA's in that general direction. To go against that grain and make a stance does not change the fact the trend exists and either you can get on board or get off the train. But as the past has shown us, if choose not to adapt, you will likely die (be replaced).
January 31, 2017 at 10:32 pm
I don't believe I am splitting hairs. The article clearly stated that you have DBAs that can do scripting and DBAs that don't who are not as efficient. That's patently not true. Like you said, there are different types of DBAs. And you being a Data Architect has nothing to do with being a DBA. 😉 For example, there is no reason in the world why you not knowing how to do a restore would prevent you from being a good Data Architect. It may help you in some decision making but it's not quintessential to your job but it is for a DBA even if they end up using some 3rd party software or PoSh script to make their job easier.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2017 at 10:48 pm
David.Poole - Tuesday, January 31, 2017 12:21 PMI loved the stack overflow cartoon https://static1.squarespace.com/static/518f5d62e4b075248d6a3f90/t/583aa5b1bebafb6551322268/1480238530975/?format=750wThese days a technical estate can be so diverse that no-one can understand it all but at the same time it is dangerous to try and operate in a silo. I feel it is important to learn basic skills outside your core specialism just so you have a common frame of reference when talking to colleagues. It makes me more flexible in the approaches I can take.
Learning a new discipline changes your mindset and stimulates the creativity that can lead to good solutions. I became a much better programmer when I learned C++ even though I never used it in anger
Just to be clear, I'm not saying that anyone should operate in a silo of single product expertise. And, yes, I agree that knowing a programming language and having the ability to script in at least one other language other than T-SQL is the way to go. What I'm taking exception to is the idea of someone writing something like PowerShell to manage their SQL Servers without knowing what's going on behind the scenes on the server. If you can't successfully do a native backup and restore, then you probably don't know enough to safely rely on writing (or, more likely, using someone else's script) to do such a thing because there's a strong chance that you won't be able to fix it in a pinch without that knowledge.
Although many think so, it's not like driving a car where you can be good at driving the car with absolutely no knowledge of how the drive train actually works. Well, unless you don't know what the third peddle on some cars is for. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2017 at 11:01 pm
David.Poole - Tuesday, January 31, 2017 12:21 PMI loved the stack overflow cartoon https://static1.squarespace.com/static/518f5d62e4b075248d6a3f90/t/583aa5b1bebafb6551322268/1480238530975/?format=750wThese days a technical estate can be so diverse that no-one can understand it all but at the same time it is dangerous to try and operate in a silo. I feel it is important to learn basic skills outside your core specialism just so you have a common frame of reference when talking to colleagues. It makes me more flexible in the approaches I can take.
Learning a new discipline changes your mindset and stimulates the creativity that can lead to good solutions. I became a much better programmer when I learned C++ even though I never used it in anger
Just to be clear, I'm not saying that anyone should operate in a silo of single product expertise. And, yes, I agree that knowing a programming language and having the ability to script in at least one other language other than T-SQL is the way to go. What I'm taking exception to is the idea of someone writing something like PowerShell to manage their SQL Servers without knowing what's going on behind the scenes on the server. If you can't successfully do a native backup and restore, then you probably don't know enough to safely rely on writing (or, more likely, using someone else's script) to do such a thing because there's a strong chance that you won't be able to fix it in a pinch without that knowledge.
Although many think so, it's not like driving a car where you can be good at driving the car with absolutely no knowledge of how the drive train actually works. Well, unless you don't know what the third peddle on some cars is for. 😉
And, to you point once more, my experience in PL/1, hand assembled machine language for the 6502 uProcessor, and several other languages have helped me tremendously. But I couldn't even begin to tell you how to even fire up VS to write something in C# and I don't need to. Heh... and to coin a phrase, I don't know beans about Java. But I do know all the ways we could have avoided spending $350K plus yearly maintenance fees and writing a shedload of JDBC for something that can easily be done in SQL Server or {gasp!} even in SSIS. 😉
Before the "New DBA is a Developer", they should first develop the skills to be a DBA. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2017 at 12:12 am
From what I can see a lot of the programming frameworks abstract developers from what goes on under the hood, period. It's not a situation limited to someone scripting something in Powershell in ignorance of what goes on in the DB.
I have to be careful here because the older we are the better we were but object design seems to be getting weaker not better and consequently schema design, whether implemented in an RDBMS or NOSQL solution is weaker.
February 1, 2017 at 2:03 am
Jeff Moden - Tuesday, January 31, 2017 11:01 PMBefore the "New DBA is a Developer", they should first develop the skills to be a DBA. 😉
I'm a developer not a DBA but I pretend to be a DBA and hope no one notices :crazy:
Far away is close at hand in the images of elsewhere.
Anon.
February 1, 2017 at 7:43 am
Heh... here's what happens when you have people that know how to script without being a DBA.
http://www.theregister.co.uk/2017/02/01/gitlab_data_loss/
Although I've not taken the time to confirm the quote below (I don't tweet nor even have a twitter account), I was especially "impressed" by the following from the article above.
So some solace there for users because not all is lost. But the document concludes with the following:
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2017 at 8:24 am
David.Poole - Wednesday, February 1, 2017 12:12 AMFrom what I can see a lot of the programming frameworks abstract developers from what goes on under the hood, period. It's not a situation limited to someone scripting something in Powershell in ignorance of what goes on in the DB.I have to be careful here because the older we are the better we were but object design seems to be getting weaker not better and consequently schema design, whether implemented in an RDBMS or NOSQL solution is weaker.
I think the proliferation of EAV designs where they have no business existing and the more and more common storage of simple text fields for later shredding instead of storing it properly makes this pretty clear.
February 1, 2017 at 8:35 am
Jeff Moden - Wednesday, February 1, 2017 7:43 AMHeh... here's what happens when you have people that know how to script without being a DBA.
http://www.theregister.co.uk/2017/02/01/gitlab_data_loss/Although I've not taken the time to confirm the quote below (I don't tweet nor even have a twitter account), I was especially "impressed" by the following from the article above.
So some solace there for users because not all is lost. But the document concludes with the following:
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
Each Git user should still have their local commits.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 1, 2017 at 10:17 am
Eric M Russell - Wednesday, February 1, 2017 8:35 AMJeff Moden - Wednesday, February 1, 2017 7:43 AMHeh... here's what happens when you have people that know how to script without being a DBA.
http://www.theregister.co.uk/2017/02/01/gitlab_data_loss/Although I've not taken the time to confirm the quote below (I don't tweet nor even have a twitter account), I was especially "impressed" by the following from the article above.
So some solace there for users because not all is lost. But the document concludes with the following:
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
Each Git user should still have their local commits.
That's nice. But you missed the point. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2017 at 4:34 pm
Eric M Russell - Wednesday, February 1, 2017 8:35 AMEach Git user should still have their local commits.
Not necessarily if they are using the branch/commit/pull request/merge/delete branch. Might be missing some work.
February 1, 2017 at 4:36 pm
Jeff Moden - Wednesday, February 1, 2017 7:43 AMHeh... here's what happens when you have people that know how to script without being a DBA.
http://www.theregister.co.uk/2017/02/01/gitlab_data_loss/Although I've not taken the time to confirm the quote below (I don't tweet nor even have a twitter account), I was especially "impressed" by the following from the article above.
So some solace there for users because not all is lost. But the document concludes with the following:
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
This isn't a scripting issue or a person not knowing how to be a DBA. This is just poor administration, regardless of job title. Plenty of DBAs have gotten into this space as well, plenty with third party backup agents that never test them.
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply