Scary Stories from the Trenches

If you have worked with databases long enough, you probably have many frightening stories to tell about things that have gone awry on the job or problems that were difficult to solve. Accidently dropping a table or trying to fix an issue with the CIO standing right in your cube, repeatedly asking if you’ve fixed it yet, are the two that immediately come to mind.

Grant Fritchey (@GFritchey) has quite a few war stories. In one of them, he was instructed to supply a backup of the production database to a developer. The developer was working on a process to send out automated email messages to customers. Since the data was not masked in any way, emails went out to real addresses during testing. That wasn’t the worst part of the story, however. Since the developer had quite a sense of humour, the messages contained, shall we say, some mature content. Luckily, Grant said he did not lose his job over this since he did exactly what he was told to do. I have a feeling that procedure changes were made quickly after that fiasco.

Kendra Little (@Kendra_little) has a story from many years ago when she was responsible for setting up a dev environment. Everything was scripted, but the process took two weeks due to all the database restores. One Friday evening a script had the wrong dev environment settings in it, and the dev environment ended up unusable. The dev team had to decide whether they would just not work for two weeks while the two-week process ran again or not be able to do end-to-end testing for the rest of the development cycle – a couple of months.

These are some scary stories, but, fortunately, there are tools that can you help avoid problems like these. Even though you can automate jobs and processes with scripts, tools can be very helpful. Take SQL Clone, for example. Kendra’s restores would have taken just seconds instead of two weeks had SQL Clone been available. And, if the private information, including email addresses, had been masked with Data Masker, Grant would have avoided this embarrassing mishap.

As humans, we are intelligent, but we also have the tendency to make mistakes. Computers are not smart (at least not yet!) but they do exactly what we tell them to do, and they can do it fast. They also don’t get bored doing repetitive tasks. That’s why DBAs like to automate as many of their tasks as possible. You’ve probably heard the term “lazy DBA,” but I call automation being smart and efficient. This is even more important as DBAs have more responsibilities due to new regulations and how IT is changing.  The more that can be automated, the less mistakes are made, and the more DBAs have time for other projects. Scripting can only take DBAs so far. That’s where the right tools for the job make all the difference.

 

The post Scary Stories from the Trenches appeared first on Simple Talk.

from Simple Talk https://ift.tt/2K3TDfn
via