August 15, 2015 at 6:38 am
Comments posted to this topic are about the item Nope to NoOps, No way to NoDBA
Best wishes,
Phil Factor
August 15, 2015 at 10:45 am
From the article:
Because we as an industry are particularly cursed with the habit of repeating our mistakes rather than learning from them, the voice of experience is mistaken for the whining of a technological dinosaur.
Great article, Phil.
The quote above struck a particular note with me. I've seen all sorts of new shiny objects appear and disappear but the fundamentals don't change. Over time, I've grown to accept the fact that there's a seemingly overwhelming urgency to adopt the shiny new objects even if the ROI is negative (or even dangerous) and have attributed it to proof of the old adage of "All kids should leave home while they still think they know it all". 😀
There's also the kid-like tendency to do exactly as you said in the quote above. Ignore sage advice (or even demonstrable proof) as the no-longer-relevant whining of a what-could-he-possibly-know "out of touch" old man. With that, there's no convincing them to not go down the path know as "Harm's Way". I'll never set someone up for failure but, sometimes, you have to let someone fail to "let them see it your way". If it doesn't cost the company much, it is sometimes necessary and even beneficial to "Give people the opportunity to fail" so that they can succeed in the future. Frequently being a voice of one against many, I've even gone so far as to have a solution ready and waiting so that when they do fail, it doesn't actually cost as much to recover. One does have to be a truly patient DBA, though, because it's really tough to watch the "kids" getting ready to put their hand on the proverbial hot stove burner and knowing that it's really going to hurt them but it's a lesson they sometimes need to experience to learn the lesson.
Of course and for many, by the time some folks learn the lessons, their advice will become the no-longer-relevant whining of a what-could-he-possibly-know "out of touch" old man with a lot of burn marks on his hands. 😉
For today's lesson, everyone should turn off all of the main and point-in-time log file backup jobs on all of their servers and deploy a centralized PowerShell script that runs from a single well connected server to control all backups on all of the servers. C'mon! It'll be fun and then you can say that know PowerShell! 😉
For those not yet interested in PowerShell, you can still have fun simply by removing all business logic in the form of constraints from your money-maker database and let the front-end and business layer handle all of that for you. What the hell. Why not? SQL Server is just a place to store data, right? As a side benefit, development is sure to go faster because you won't actually have to make any test data that comes close to what is actually needed. You certainly won't ever have to worry about figuring out table hierarchy or being rejected by those pesky primary keys or foreign keys and you'll be able to truncate any table at any time to do another test with. Even better, your inserts will run like lightning! :w00t:
And for goodness sake, don't worry about performance in that one bit of code the DBA has been bugging you about. After all, the table the code works with will never contain more than a couple of hundred rows, right? Stoopid ol' man... what does he know? He just keeps slowing us down on all the rework we've been assigned! Plus, our lead developer has found a way to solve all of our performance issues. We're changing all the columns in all tables to NVARHAR(MAX) so that we'll never have to worry about datatype mismatches or column length limitations ever again! :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
August 15, 2015 at 3:41 pm
It sounds like you've worked at the same places I have.
Best wishes,
Phil Factor
August 15, 2015 at 8:11 pm
And how about we assign GUIDs for all primary keys? ... oh ... and clustered too ... No one listened to this veteran, and while we're at it let's migrate the business to an ORM and worry later about performance issues 🙁
August 16, 2015 at 4:03 pm
Phil great story.
I had a similar thing here
I was asked to do a Mysql Load balanced cluster.
Not being something I'd done before, or this department had done I read up a bit and submitted a time frame of about 3 weeks to setup a trial.
I was told it needed to be done by friday for a new core system to go live.
When I said I didn't have those skills they got a contractor, who they reportedly paid $5k for 2 hours work.
When the system went live it lasted around 30 seconds and then the transactions got "confused".
Within 5 minutes it was on the MSSQL failover cluster.
There was no production load testing just go live - thankfully the lead developer now works somewhere else.
August 17, 2015 at 2:04 am
If you want to understand how something works try and change it.
I've been playing around with NOSQL for long enough to know that if you choose the right tool for the right job and give it to someone competent you get desirable results. You definitely need those 3 or at least a lead developer with all 3 and a well worn heavy duty learning bat!
The problem with NOSQL is exactly the same as with RDBMS. PEBCAK. Problem Exists Between Chair And Keyboard. The same muppets cocking up an RDBMS are the same ones who will kill your NOSQL solution.
August 17, 2015 at 7:15 am
pparsons (8/15/2015)
And how about we assign GUIDs for all primary keys? ... oh ... and clustered too ... No one listened to this veteran, and while we're at it let's migrate the business to an ORM and worry later about performance issues 🙁
Primary keys? Rubbish, that's just relational bulls... it just doesn't apply to real world development. Etc.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
August 17, 2015 at 7:20 am
david.andrew 41944 (8/16/2015)
Phil great story.I had a similar thing here
I was asked to do a Mysql Load balanced cluster.
Not being something I'd done before, or this department had done I read up a bit and submitted a time frame of about 3 weeks to setup a trial.
I was told it needed to be done by friday for a new core system to go live.
When I said I didn't have those skills they got a contractor, who they reportedly paid $5k for 2 hours work.
When the system went live it lasted around 30 seconds and then the transactions got "confused".
Within 5 minutes it was on the MSSQL failover cluster.
There was no production load testing just go live - thankfully the lead developer now works somewhere else.
Does the run-book there contain the phrase "... fries with that?"
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
August 17, 2015 at 7:52 am
I enjoyed reading this article. I've worked at one place where we made a really good first attempt at a proper DevOps setup, and (after some initial resistance from the developers) we all got along pretty well and got some good work done. The next place I went, I actually joined the DevOps team, so I had high hopes, but unfortunately it became apparent pretty much straight away that they had no concept of what it really was, and just seemed to have picked up on the latest buzzword.
August 17, 2015 at 8:05 am
David.Poole (8/17/2015)
If you want to understand how something works try and change it.I've been playing around with NOSQL for long enough to know that if you choose the right tool for the right job and give it to someone competent you get desirable results. You definitely need those 3 or at least a lead developer with all 3 and a well worn heavy duty learning bat!
The problem with NOSQL is exactly the same as with RDBMS. PEBCAK. Problem Exists Between Chair And Keyboard. The same muppets cocking up an RDBMS are the same ones who will kill your NOSQL solution.
Heh... so rather than add to the proverbial "Tower of Babel", just cock it up in the RDBMS. 😛 At least you'll have a DBA that can help there.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2015 at 8:07 am
Phil Factor (8/15/2015)
It sounds like you've worked at the same places I have.
Side by side a pond apart, ol' friend. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2015 at 8:35 am
@Beatrix Kiddo
So often for DevOps, read 'Let the Lunatics take over the Asylum'
@jeff Moden
I think that once you've worked out how an RDBMS does stuff like ACID, you can cut it by hand in any system you are told to use, however foolish the instruction. That system of checking the logs in MongoDB was pretty ingenious.
Best wishes,
Phil Factor
August 17, 2015 at 10:00 am
Excellent article, and sadly, yes, similar mistakes keep getting repeated. Back in the early 90's, it was non-IT people in the business enterprise writing all manner of mission-critical 'applications' in MS Access behind our backs - and then panicking for IT help when their data mysteriously disappeared or corrupted. IT quickly went from being perceived as a roadblock to the fount of all wisdom.
And today's received wisdom? It's always best to involve your friendly local DBA if you're a developer.
August 17, 2015 at 10:26 am
A wiki for people in technology to document issues might be a helpful tool in learning from our mistakes.
Does anyone use one?
412-977-3526 call/text
Viewing 15 posts - 1 through 15 (of 27 total)
You must be logged in to reply to this topic. Login to reply