February 1, 2017 at 5:18 pm
This is just poor administration, regardless of job title.
Databases don't just live in SQL Server. Just like job titles, databases come in many forms. And "Just poor administration" is exactly what I'm talking about, regardless of job title. How many times have we seen posts by "administrators" on this very site requesting info on how to recover a database with no backups available? People doing the job of a DBA need to learn to be a DBA before they start writing or using scripts to do DBA things. 😉
And, YES! It absolutely WAS a scripting issue. It was a handwritten DOS script that blew away the data.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 1, 2017 at 5:59 pm
Jeff, that's just not true.
It was not a scripting issue. It was a connection issue. The user ran their purge commands against the live server, not the secondary server. This deleted the data. For all we know, this was a competent and experienced database administrator that made a mistake.
I agree that anyone administering a system needs to have some knowledge about how the system works and the implications of their work. However, competence at your job isn't a function of trying to learn something new. It's an issue with training, with responsibility, or personal effort to improve your abilities. That is separate from what you learn, or choose to learn. You keep wanting to conflate the fact that many people are not competent at their jobs with various technologies. Those are not issues with the cloud, with many of us learning more about different areas, or scripting. Those are issues with employers asking for responsibilities their staff may not be competent at, and/or with employees trying to perform tasks in live environments without sufficient skill.
February 1, 2017 at 7:44 pm
Steve Jones - SSC Editor - Wednesday, February 1, 2017 5:59 PMJeff, that's just not true.
It was not a scripting issue. It was a connection issue. The user ran their purge commands against the live server, not the secondary server. This deleted the data. For all we know, this was a competent and experienced database administrator that made a mistake.I agree that anyone administering a system needs to have some knowledge about how the system works and the implications of their work. However, competence at your job isn't a function of trying to learn something new. It's an issue with training, with responsibility, or personal effort to improve your abilities. That is separate from what you learn, or choose to learn. You keep wanting to conflate the fact that many people are not competent at their jobs with various technologies. Those are not issues with the cloud, with many of us learning more about different areas, or scripting. Those are issues with employers asking for responsibilities their staff may not be competent at, and/or with employees trying to perform tasks in live environments without sufficient skill.
Again, I have to disagree. Whether it was a single line typed on-the-fly manually or a single line stored in a file, it's a script. And I do absolutely agree that people should learn new things. But the first "new" thing they should learn is how to be competent at the job they're supposed to be doing. The "Git" incident is a prime example of what happens when people aren't (remember that a whole bunch of "backup" methods had either been failing or weren't implemented to begin with). And the issues aren't always with employers asking for responsibilities their staff may not be competent at. The issue with a huge number of supposed "DBAs" (in quotes because they're not actually DBAs) is that they copy scripts from the internet to do their jobs because they don't actually know how to do the job their being paid for. They can, however, tell on the resume the near lie about how they used the whiz-bang PowerShell methods to maintain their databases. 😉
My point is "YES", I absolutely agree that people should expand their horizons and, YES, the "new" DBA is also a developer but I'm finding too often that being a developer has come first instead of being a true DBA coming first. My second point, as I also state early on, is that it's not "new" that a DBA is also a "Developer". Good DBAs have always been "good developers" as well as DBAs.
But my biggest point is that I disagree with the quote I copied from your good article. You don't actually need to know how to script to be an "efficient" or good DBA. 😉
At that, it may be that we'll have to agree to disagree, ol' friend. Thank you for letting me say my piece and I'll stop now. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2017 at 2:45 am
Wow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.
February 2, 2017 at 6:34 am
Yet Another DBA - Thursday, February 2, 2017 2:45 AMWow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.
Heh... that sounds a bit like what he might do. Make a stab with no explanation. Care to qualify your unqualified statement?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2017 at 6:56 am
Jeff Moden - Thursday, February 2, 2017 6:34 AMYet Another DBA - Thursday, February 2, 2017 2:45 AMWow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.Heh... that sounds a bit like what he might do. Make a stab with no explanation. Care to qualify your unqualified statement?
I thought it was self explanatory. But, suppose it depends on your point of view.
February 2, 2017 at 11:13 am
This situation about the VCS database not getting backed up properly; I suspect that's common. The problem is that for many organizations the VCS is not treated with the same respect as the production line of business servers; often being installed and managed outside the domain of the DBA and operational team.
Years ago, when working for a previous employer, there was a SAN failure, and we lost the repository for Team Foundation Server with no backups. From what I recall, it was the QA team who installed and "managed" it. At the time, I was a developer and not responsible for any of it. We all basically had to fall back to checking in the latest version of the projects that were cached locally on our PC and essentially lost all of our file version history, tasks, and workflow.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 2, 2017 at 12:19 pm
Yet Another DBA - Thursday, February 2, 2017 6:56 AMJeff Moden - Thursday, February 2, 2017 6:34 AMYet Another DBA - Thursday, February 2, 2017 2:45 AMWow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.Heh... that sounds a bit like what he might do. Make a stab with no explanation. Care to qualify your unqualified statement?
I thought it was self explanatory. But, suppose it depends on your point of view.
Correct. I'd be interested in why you think hairs are being split.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2017 at 12:53 pm
Yet Another DBA - Thursday, February 2, 2017 2:45 AMWow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.
I was actually enjoying the debate as I don't care to engage in those myself but I thought they did a great job. From my perspective, it was two very bright people who definitely know database administration incredibly well but who also seem to generally come from different perspectives. I saw merits in both sides of the argument so that always provides something to think about, for me anyway. Despite both being passionate about their differing views, they were direct while being respectful of each other and leaving things where they could still be friends at the end of the day.
Didn't mean to spoil the party - you all can go back to arguing now 🙂
February 2, 2017 at 2:00 pm
Sue_H - Thursday, February 2, 2017 12:53 PMYet Another DBA - Thursday, February 2, 2017 2:45 AMWow, there is so much hair splitting on this thread that it would make Joe Celko look like a long hair hippy.I was actually enjoying the debate as I don't care to engage in those myself but I thought they did a great job. From my perspective, it was two very bright people who definitely know database administration incredibly well but who also seem to generally come from different perspectives. I saw merits in both sides of the argument so that always provides something to think about, for me anyway. Despite both being passionate about their differing views, they were direct while being respectful of each other and leaving things where they could still be friends at the end of the day.
Didn't mean to spoil the party - you all can go back to arguing now 🙂
Exactly. These types of discussions bring out a lot of different ideas and points of views. As is frequently seen, the discussions associated with an article can bring great confirmation of the subject of the article as well as alternative ideas and information especially when it's between a couple of folks with such a difference in ideas. Heh... and sometimes the hair being split is as wide as a tree for one, the other, or both. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 7, 2017 at 9:41 am
Jeff Moden - Tuesday, January 31, 2017 7:56 AMp.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.
Well, of course most "good DBAs" have always written scripts, even decades ago. However, that doesn't mean that most DBAs wrote scripts back in those days, because there were an awful lot of not good DBAs.
I used to work on the theory that a good DBA for a relational database had to be competent in two scripting languages: SQL plus depending on the RDBMS he was using one of T-SQL, PL-SQL, and QEL. But most of the relational DBAs I knew decades ago couldn't even write any SQL. The used some sort of GUI.
When in 2002 I joined Neos and took on responsability for the both the databases of Neos and those of its customers I wrote and tested backup scripts and wrote and tested and verified restore scripts and created agent jobs to run appropriate backups at appropriate intervals; that didn't take much time. Next generated scripts for all the tables, views, stored procedures, and functions in all the databases plus ll the agent jobs and got them into a source control system so that in future there would be control and there would be version history; That's what whoever was the original DBA for those databases should have done long before I went there, but none of it had been done. The original DBA was a typical old-style DBA. He couldn't write scripts, not even in SQL, and none of the customer's databases had been backed up - ever.
Tom
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply