Voice of the DBA

Category: Editorial

  • It’s the Engineers

    There are all sorts of articles and blogs on the Internet that try and teach you how to use a particular technique or technology to solve a problem. Plenty of this information is well written, and showcases the knowledge of that individual (or team) and how they’ve built a fantastic system. Every vendor building software platforms has reference case studies that show how well their system has worked for some customer. These are all good models that might give you confidence why SQL Server or MongoDB or Entity Framework or GoLang are good choices for your company.

    In reality, it’s not as simple as just choosing a platform or framework or language to make your application perform better. You really need the staff that understands how to use your choice of X and has some skill in building a system in that manner. It’s why I think that the cost of the software is a pittance compared to the cost of your people. If you have to train them, or they need to learn how technology X works, then you’re going to pay more in salary than you’d save in software licenses.

    There’s an article that I think illustrates this well, and might be worth passing along to your developers. It’s called Why Amazon DynamoDB isn’t for everyone and it’s worth a few minutes of your time to read. The gist of the article is that a NoSQL system, like DynamoDB, isn’t as simple and easy as you expect. It also says that for many applications, a relational database is a better choice because it’s often better understood and will solve most problems at small scale. For most of us, we don’t really get past what I’d consider small to medium scale, and so we should stick with relational systems.

    This isn’t to say that DynamoDB will be a problem for you, but there will be a learning curve for your developers if they haven’t used it in production and at your scale. The same thing occurs if a development team decided to switch from MongoDB to SQL Server because they like automatic tuning. They won’t necessarily configure and use SQL Server efficiently, and might not have their application perform well. Switching your development paradigm or technology is hard, and it will take time for your staff to get up to speed.

    Ultimately it really comes down to having good engineers that can write good code and understands the ins and outs of administering that particular platform. The database is extremely important here as it is the central location of your information, but the same arguments apply to frameworks and languages. As much as we want to learn and try new technologies and incorporate them into our work, we need to realize that it takes time to learn to use them well. Make small experiments, try POCs and slowly build up skills before you decide that your mission critical system needs some new technology that you read about and are excited to try working with.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • It’s Time to Patch and Upgrade

    I don’t want to be chicken little here, but the Meltdown/Spectre bugs have me concerned. I don’t know the scope of the vulnerabilities, as far as exploits go, but I do know the lax ways in which humans interact with machines, including running code, opening untrusted documents, and just making silly mistakes. No matter how careful you think you are, can you be sure everyone else in your organization is just as careful? Are you sure they won’t do something silly from a database server? Or do something from a server (or workstation) that has access to a database server? Or use a browser (yes, there’s an exploit)

    PATCH your system, soon.

    Vulernabilities in hardware are no joke, and even if you think you’re fairly safe, it’s silly to let this one go by and assume you won’t get hit. The advent of widely deployed scripting tools, botnets, and more mean that you never know what crazy mechanism might end up getting to your database server. Is it really worth allowing this when you can patch a system? This is a no brainer, a simple decision. Just schedule the patches. With all the news and media, I’m sure you can get some downtime approved in the next few weeks. After all, your management wouldn’t want to explain to their customers any data loss from this any more than you’d want to explain it to your boss.

    We’ve got a page at SQLServerCentral that summarizes the links I’ve found for information, patches, etc. I’m sure things will change rapidly, and I’ll update the article as I get more information. The important things to note are that not all OSes have patches yet, and there are situations where you might not need to change anything. That’s good, as there are some preliminary reports of patches causing issues with performance (degrading it) for PostgreSQL And MongoDB systems. I did see this tweet about no effects on SQL Server, which is good, but YMMV.

    Most of us know patching matters, and we need to do it periodically (even if it’s a pain), however, many of you are like me in that you rarely upgrade systems. Once they work, and because I have plenty of other tasks, I don’t look to necessarily upgrade a database platform for years. One downside to that is that a major vulnerability like the Meltdown/Spectre attacks is that patches likely won’t come out for old system and versions of SQL Server. That is the case here.

    That means that if you’re on SQL 2005-, or even on older Windows OSes, you might really consider planning an upgrade. Even if you aren’t overly worried about this exploit, you won’t want a vulnerability to live for a long time in your environment. You never know when a firewall will change, server will move, or some malware will slip through (did I mention the browser exploit?). Plan on an upgrade. I’ve started asking about accelerating our upgrade plans, and you might think about that as well. I know management doesn’t want to spend money unneceesarily, but this feels necessary, and a good time to refresh your system to a supported version.

    In general I like to delay my patches slightly from the world and not be on the bleeding edge. That’s fine, but don’t wait too long with this one. I would hope that most people get systems patched in the next month. If not, don’t expect any sympathy if you lose data.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Using Better Tools

    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.

  • No Magical DevOps

    I saw this comment in a post a short while back. A reader said “I’m still trying to wrap my head around “devops” as it pertains to database deployment. … how do you deal with those potentially dangerous/destructive changes without manually coding? … what tools are there that help in that regard? That’s what database developers really need. The only tools I’ve found that’ [are] useful so far are experience and care.”

    We have some tools over at Redgate software to help with database DevOps, but there aren’t any magic solutions that can alter your database in some way that doesn’t impact users and preserves all data. In fact, if anyone claimed to have a tool, I wouldn’t trust it because there are just too many variables in database deployments. I certainly wouldn’t trust a tool with automated rollbacks. Ultimately, experience and care are needed to build better software.

    And, by the way, DevOps doesn’t solve deployment issues. All DevOps does is help you automate the tasks you’d run manually in a reliable, repeatable fashion. DevOps teaches you to learn from your actions (gaining experience) and experimenting with small changes so that your mistakes aren’t as impactful (developing with care). DevOps isn’t magic, it’s good, solid, learning from what works and what doesn’t, altering our habits, and striving to be better. DevOps is often just providing a reliable, repeatable way of automating the things you do manually now, not inventing new processes.

    I do believe in DevOps and I think that it can work well, but it requires balance, commitment, and huge culture changes. Automating code deployment is easy with some tools. Getting people to write better code is hard. I can help with the former, and I try to help with the latter here at SQLServerCentral, but it’s really up to most of you to make an effort to become better at your craft. Getting that to work in any size organization requires that your management supports teams learning to be better and tolerating a few mistakes here and there.

    Many successful developers and DBAs have been practicing for many years (even decades) what the media and high profile companies have been calling DevOps for mere months. You can join them by looking to improve all parts of your software development pipeline through collaboration and automation. Just don’t forget to also learn to write better code along the way.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.