Voice of the DBA

Author: way0utwest

  • The Impediments to Change

    SQL Server is releasing a new version of the engine every 12-24 months at this point. That puts pressure on all of us to learn constantly about the changes. Even if we don’t look to upgrade all of our existing instances, we can’t buy older versions when the new one is released. Often many of us would like to install the latest version for new systems, but that isn’t always possible. If we can, then we have a new version to support.

    Recently I was reading ArsTechnica and they posed a question about the impediments to adopting new technology at work. Their query was in the form of a survey, and they’d like you to answer if you can. I took the survey, and I thought it was a bit vague in some sense, mostly around networking and communications rather than other areas, but perhaps that’s their focus.

    In any case, it often can be difficult for some companies to decide to upgrade their database servers. Licensing cost is a real concern, and while it pales with the cost of labor, I am not sure I’ve seen many features that would actually reduce labor costs significantly. Most the features might make some aspect of development easier (or quicker), but often we have solutions or code in place that we don’t want to spent time changing. Upgrading older platforms is also a nebulous proposition. The improvements in HA/DR, quicker data loads, and more might be worth changing versions, but the capital cost can be hard to justify. Deciding to install the latest version for a new server isn’t necessarily going to reduce any labor costs, and it could increase them, since staff now needs to understand the new platform.

    Perhaps hardware inhibits you from making changes. Is there a point in upgrading from SQL 2008 to SQL 2017 for working applications if you don’t change hardware? Is it worth buying modern hardware? Glenn Berry would argue yes, but not everyone agrees, especially in upper management. This might even be true in upgrading minor parts of your existing system. Can you add RAM? Cores? Does your storage subsystem ever receive improvements? While hardware is certainly a capital expenditure, small changes could make big impacts to users, despite the reluctance to invest in older systems.

    Are there other reasons you don’t upgrade? Is staff knowledge an issue? Perhaps you have concerns about support personnel having to work with new systems. There might even be other reasons to avoid change. Time might be the biggest one with people busy on other projects. If you have some thoughts, drop a note in the discussion today. I’d be especially interested if you have Software Assurance and don’t regularly take advantage of that to upgrade. We’d also love some short articles on your experiences upgrading if you’re willing to write about them.

    Steve Jones

    Listen to the podcast at Libsyn.

  • SQL in the City Christchurch–June 7

    I’m going to New Zealand for SQL in the City Christchurch on June 7. It’s a day before SQL Saturday #831 – South Island. Take two days and get lots of Database DevOps and SQL Server training for a very low cost. I don’t know how many events come to New Zealand, but I’m hoping lots of you can come to our event and we’ll have the chance to do it again.

    Register today for a full day of training and talks about DevOps and Redgate products on Friday, then come back to SQL Saturday 24 hours later.

    I’m excited for the event. We completed our London Summit last week and it went very well. I’m taking over the keynote from Kendra and also doing a Monitoring session as well as covering privacy and the panel.

    It’s going to be an exciting day, so if you want to improve your Database DevOps process, in a Compliant way, sign up and come on June 7.

    2019-05-02 11_33_08-Window

  • The Death of the GDPR

    When I first heard of the Sarbanes-Oxley Act, I was disheartened. It sounds like another over reaction by politicians to a crisis that would create lots of work for companies. At the time I was working for a software vendor and while we weren’t bound by many regulations, we did value our ISO certification. As we went through the SOX audit, it felt a lot like our ISO audit the previous year. In fact, we re-used most of our work, and re-did some, making it compliant with both items.

    A few years ago, we started GDPR preparations at Redgate, as well as talking and working with customers. We built some products, like SQL Provision and our Data Catalog, with the hope that they would be useful to organizations looking to ensure compliance. We have seen many companies trying to comply, and I’m glad that we can help. I think the GDPR is a step in the right direction for the future of how we manage and deal with data.

    I’m also glad that companies are taking the idea of data rights and data privacy more seriously. I think those of us in technology have been lax, and management of many companies even worse. I think I may some some evidence in this piece about possible lack of enforcement of the GDPR by Ireland. Not to discuss politics, but I completely understand when a very large company brings a lot of revenue to a country, there will be hesitation in disturbing that relationship.

    Regardless of the politics, I did find this quote interesting. A report in 2011 on Facebook’s data handling practices had this quote: “We do not consider that reliance on developer adherence to best practice or stated policy in certain cases is sufficient to ensure security of user data…” This didn’t prompt Facebook to make changes to process, and Ireland has not pressured them to do so, even with the GDPR taking effect last year. I’m hoping this isn’t the death of the GDPR as a set of regulations.

    I completely agree with the sentiment of that quote. We can’t trust that developers will adhere to best practices, or that companies will protect data. Sometimes this is ignorance, sometimes human error, and other times willful disregard for rules and regulations. We do need some sort of enforcement of the data handling practices that we as a society want to see in place. We certainly have to decide what practices to codify in our framework and we need some enforcement.

    I don’t know that very large tech companies will get fined or forced to better handle data, but for many of us that work in smaller organizations, we don’t have the clout or impact of a multi-billion dollar revenue organization. We might see fines that can very much hurt our businesses. We ought to be ensuring we not only follow best practices, but we build data security in by design and default. It’s cheaper and easier to do so, and it ensures we don’t fail to go back and fix things later.

    It’s also something each of us, as data professionals, ought to take pride in doing.

    Steve Jones

    Listen to the podcast at Libsyn.

  • Default Backups and Feature Awareness

    Have you ever been asked a question about your software and thought that the person was asking about an obvious feature? Perhaps someone has suggested a feature to you and you answered that this was already in the product. Did any of you think your users were stupid or not very observant, or something else?

    I’ve had that situation appear a few times, with me on different sides of the discussion. I watched someone ask a question that I knew the answer to, and thought, huh, why didn’t they know that? I asked a question about something in the Microsoft Azure world and got a quick answer, wondering why I hadn’t been able to find the solution myself, and that I shouldn’t have been cursing the Microsoft developers so much. I’ve had a few people do strange things at SQLServerCentral after the migration and wondered, why in the world…….? Then I remember that lots of people use the site differently than I do and I should expect that.

    I thought about this while reading Joey D’Antoni’s piece on backups. It’s not hard to make backups. It’s not hard to set up a maintenance plan to run backups. It’s not hard to set up a history task to trim old ones. Heck, it’s not hard to implement Ola’s scripts.

    The problem is all of these solutions require some knowledge.

    I think plenty of people assume either the system backs itself up or their nightly file sweep by a central backup system will grab the database. Hint: it won’t. I think plenty of people think backups are someone else’s job, or they are in a hurry with an installation and assume they, or someone, else will return and set up backups later. Plenty of third party software may create a database, but never set up a backup process. We often don’t realize no backups are running.

    That’s not good. While I like Joey’s suggestion, I’d go further. I’d have instance defaults set on install and an automatic, nightly full backup process set for all new databases with a week’s retention. I’d embed this in the DDL so the default is backups will be set on CREATE DATABASE, and you can use a switch to turn this off if you want to use some other backup process. I bet backup software, like SQL Backup, would even do this for you, turning off native backups when you turn on their scheduler.

    I think backup is the most critical thing a DBA does, or an accidental DBA, or the accountant that installed Dynamics, or anyone working with a database. Next would be verifying things with a restore. Then comes security and the list goes on from that point. If you don’t have the data, because of ransomware, virus, bad hardware, or anything else, you are in a bad situation.

    Please. Set up backups. If you find a server without them, inform someone in writing of the dangers and give them resources for creating backups. If you create databases as part of your software deployment process, set up backups somehow. Use a maintenance plan. Those aren’t great, but they’re better than nothing. There’s a reason why SQL Monitor has an alert for databases with no backup. It’s a critical one to have running.

    Steve Jones

    Listen to the podcast at Libsyn.