Category: T-SQL Tuesday

Denis Gobo explains some of the learning experiences he has had over the years:

Use SQL to bring down other things in the company
The request was that support wanted to know immediately when an order was placed. No problem, we can add a trigger that populates a table and then we have a job that runs once a minute to email the support group. Sounds reasonable right? Someone decided to do a little testing…. this person created 100,000 entries…. I guess you can imagine what happens next. Yep, the email server was overloaded. We had to quickly delete these rows and truncate the table that was used to send the emails.

Good ol’ eDOS (e-mail Denial of Service) attacks…

Arun Sirpal lets out a dirty secret:

We are here to talk about mistakes we used to make. There is one mistake that I am going to discuss and is something that I used to do 10 years ago, obviously I do not do this anymore.

I USED TO SHRINK DATABASES

There, I said it! Why did I do this? Well I never knew any better. Why shouldn’t you do this?

There are situations where a database shrink operation makes sense.  Those cases are quite rare.

Grant Fritchey puts a bow on the latest T-SQL Tuesday:

Thank you to everyone who participated in T-SQL Tuesday #091 which was on databases and DevOps. As I anticipated, this brought out quite a bit of variety on the posts. This is because DevOps is still… not quite cooked…(?) in many peoples minds. I think with the range of posts we saw here, it’ll be a lot more clear to those who are just getting an introduction to it. Here are the posts (in no particular order) and a few comments on each:

Click through to see all the entrants.

Richie Lee has an essay comparing Minecraft to DevOps:

Let me be clear about something: If you don’t have your databases in source control, there’s no point in thinking about anything else. Everything else follows on from this point. Getting your code in source control is the absolute starting point of all deployment pipelines. Some people have very strong views about whether to use git or TFS, but frankly I’m less concerned about the SVN of choice and more concerned about whether all code that is deployed is in source control. But the point is there’s no point in fretting about how to use Octopus Deploy if you haven’t got your code in source control.

The morals of this story are to crawl before you walk, and when you do learn to walk, don’t walk on lava.  I like the extended Minecraft metaphor, which sets this post off from many others of its ilk.

Rob Farley explains the basics of DevOps:

Traditionally, developers would develop code without thinking much about operations. They’d get some new code ready, deploy it somehow, and hope it didn’t break much. And the Operations team would brace themselves for a ton of pain, and start pushing back on change, and be seen as a “BOFH”, and everyone would be happy. I still see these kinds of places, although for the most part, people try to get along.

With DevOps, the idea is that developers work in a way that means that things don’t break.

I know, right.

My tongue-in-cheek-or-maybe-not version of this is, DevOps is when you put developers in the on-call rotation.  This provides motivation to build tools that actually explain what’s going on and write code that plays nicer with others.

Andy Yun explains how he sees DevOps:

In the world of DevOps, an Operations team might utilize a monitoring tool that feeds useful directly back to Developers and Testers. Developers & Testers may cross train, so both learn how to effectively write automated unit tests. Developers & Testers could cross train with Operations, to improve application deployment automation processes.

These examples all share one common theme – teams reaching outside of their traditional skill boundaries, to actively engage, learn, and integrate. This active engagement is what has often been missing from traditional operations.

Andy’s post is a good example of the positive take on DevOps (and the one to which I subscribe).