January 9, 2019 at 9:05 am
Comments posted to this topic are about the item Is Failure Allowed?
January 9, 2019 at 1:42 pm
I haven't used SQL Server in a professional context for 5 years but I have used what I have learned from my past life as a SQL Server DBA and from the way the Redgate tools approach things to find ways of facilitating safe experimentation.
Page 16 of the Redgate State of Database DevOps 2018 highlights the areas on which to focus.
Local experimental environments are essential. Scripting the production DB and keeping it under source control is also a corner piece of the puzzle.
Thinking about how you would test a scenario adequately and then designing mechanical test scripts to carry them out. Every meaningful test reduces the risk for the eventual live deployment. What i have found is that the tests find problems I would not have expected and early enough to address while developing. It's uncovered unexpected tech debt.
The important bit is to recognise that every step forward is a step forward. Just because it doesn't answer every question doesn't negate the value of what has been achieved.
January 9, 2019 at 6:51 pm
As a DBA, you are expected to be more diligent about your work, more experienced in everything you do - especially if you've never done it before, and know a lot of things about every intricacy of SQL Server. This is why many of us are plagued by the Imposter Syndrome and probably always will be. Heck, most of us can't even attempt to do the things we'd like to try on a Test box with a smattering of decent sized databases on them, in case our bosses find out we're trying something new in our spare time on their dime, even if it's after hours!
January 10, 2019 at 7:05 am
...This is the same type of experiment I might conduct with a schema that I need to evolve. I'd make a copy, move some data, perhaps in a second database where I use views, synonyms, and other objects that can help me understand the impact of making design changes on my application. If I've captured the scripts in a VCS (perhaps a branch), and documented the changes, I could easily repeat this in the future in my production database, knowing the steps to follow that will minimize disruptions.
...
Steve,
The type of experimental based prototyping and refactoring you just described accounts for at least 30% of what I normally do. I guess the level of experimentation varies from one DBA or IT organization to another.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 10, 2019 at 10:03 am
It certainly does, especially dependent on the workload and resources available to prototype.
January 10, 2019 at 2:32 pm
As the Mythbusters frequently said, “Failure is always an option.”
Nobody gets everything right the first time, all the time. Developers and DBAs need to be able to experiment and try new things to learn what works best in their environment. Granted, it is generally easier for developers to do that since code that fails QA just goes back to development for another pass. A DBA’s changes can break things for the entire development team if things go sideways. Then there are a group of developers looking for something to do while the database changes are rolled back via scripts or a restore. Still worth the lessons learned.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply