There are good tools available to help you work with your SQL Server database or build better applications. Microsoft has built some, most of which I think are basic and not great, but plenty of third parties have offered products in the Microsoft ecosystem that can help you build better systems. I work for a software vendor (Redgate Software). We build all sorts of tools to help you work with SQL Server. I enjoy working for Redgate because I think we build some great software that’s valuable, and I hope you check us out. Most of our our utilities cost money, but we have some cool, free tools, like SQL Search and DLM Dashboard.
I get that some organizations don’t have the budget for third party tools. That’s too bad, but there are some good tools out there, and I think many of us vendors do provide value in saving you time and effort in working with the Microsoft platform. If that’s worth the cost, you should consider using tools. At the very least, you should be aware of the free and paid extras out there and consider the ones that help you.
What I find strange is that some orgs don’t allow any third party tools, free or paid, because they don’t come from Microsoft. They may even disallow utilities like sp_Blitz, sp_whoisActive, and the dbatools project. What I don’t understand is why there is a blanket ban on software from companies other than Microsoft? How can you not take advantage of these tools? I get that many companies might not want a developer or DBA installing some random software on their system whenever they want. There are good reasons to not do that, but there are also good reasons to test and use actual code that is useful, even if produced by someone else.
What’s also interesting is that rarely find an issue with Ola’s backup scripts, so why would Minion Backup or these other tools be different? After all, most of these are open source, so you can see the code. It’s really no different than the code that an employee might write, howover many companies don’t have employees that can write this software. You can see the Powershell for dbatools on Github, so what’s the issue? You can test this code like you might test your own code. In fact, you should aways do this, but you can also count on other people having tested this code as well, perhaps in ways you wouldn’t think of exercising it. You might even be doing this, with employees cut and pasting code from one of these utilities on your system and passing it off as their own work.
Every company might need restrictions on code that goes to production systems. Certainly they should have ways to patch and update this code, especially as many of the issues found from open source software stem from organizations not applying patches. All code should be tested and verified, whether written by FTEs, contractors, purchased, or downloaded from the Internet. However, once you can verify code, there shouldn’t be restrictions on deploying code just because it wasn’t written by Microsoft. After all, many in the community might write better code than Microsoft, and often do.
Take advantage of the tools that are out there. Use free ones if you can and buy third party products if they give you value for your money. However, don’t just say that we can’t install something because it’s not on the install media. Your build process should be scripted, treating configuration as code, and add those useful (tested) tools to all your systems.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 4.8MB) podcast or subscribe to the feed at iTunes and Libsyn.
