Voice of the DBA

Author: way0utwest

  • Working Hard in Baton Rouge

    I’m heading back to Baton Rouge for SQL Saturday #749 this August. This is one of the largest SQL Saturdays in the US, and one I really enjoy. I’ve been there 5 or 6 times, and I was honored to be selected again.

    But they’re working me. The schedule is out. I’m doing three sessions, the first three of the day. You can some see me talk about:

    If you’re in the area, this is a great way to get some training on SQL Server and .NET. There are lots of really good sessions from some experts, including the Power BI experts, Adam Saxton and Patrick LeBlanc.

    Hope to see you near the Big Easy this August.

  • Storage that Expires

    Whether you like the idea of the GDPR (and the new California law), I’m sure you agree that these laws will likely change our data handling in business. Even if they are weakened through legal challenges, many companies have already started to comply and change some of their practices.

    I’ve written about the GDPR plenty of times this year, and I like the law. I hope the law stands strong and resists most challenges. While I’m sure there will be plenty of spurious or silly requests and complaints, I do think these laws are asking for the good data handling practices that most data professionals have advocated for years. These include not only security but also integrity. How often have many of us advocated for corrections to problematic data and been told no? How many times have we complained about security practices?

    One area that I think has been neglected too long in most industries is the area of retention. Most companies I’ve worked for have retained data indefinitely, without any thought or policy. In my mind, we ought to explicitly think about how long we hold data, and remove older data that isn’t needed for our organization’s operation. I feel more strongly about this over time as we find that data beaches become more and more prevalent.

    Azure has started a preview of immutable storage, essentially WORM (Write Once, Read Many) drives as an Azure container. I’ve used WORM storage, but it’s often been viewed as a way of keeping information forever. that can change with this new Azure storage, as you can set a lifecycle management period. The blobs will be removed after this time, which removes one management headache from administrators.

    I could see quite a few uses for this type of storage. If it’s inexpensive enough, what about storing backups here? We could have policies set to remove files after some limited period. I’m sure there are plenty of other uses for storage the is immutable, but also contains lifecycle management options. What creative use would you have for this type of expiring WORM storage?

    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.

  • The End of Support

    With the accelerating pace of development and more frequent releases, we are seeing a bunching up of SQL Server support milestones. From 2008 through 2016, we had a new version every two years. Last year we saw another version, which means 5 versions in a ten year span. With 5 years of main support and 5 of security patches + extended support, Microsoft has quite a few active branches of code.

    We now see SQL Server 2008 and R2 coming to the end of support on July 8, 2019. There are plenty of options for customers, including doing nothing. After all, if you’ve been running SQL Server 2005 or even 2000, you’ve been without support for some time. That might not be a policy of your organization, particularly if you adhere to any standards or are bound by regulation. In those cases, you may need to have active support under contract.

    There is a good argument to be made that you should have active support for your core systems, such as the OS or your database platform. If a bug or security issue is discovered, would you want to upgrade on a very short timeline or apply a patch to your existing version? Think about running SQL Server 2008 today and a critical security problem is discovered in October. Do you want to upgrade to SQL Server 201x this year? Or would you wish that you would have planned and executed an upgrade in June and have to apply a GDR patch in October?

    I tend to view patches as much lower risk than an upgrade, mostly because the number of changes is smaller, and an upgrade reduces my options, not to mention often increases my costs. That might change over time, as I upgrade other instances and gain experience with a new version. SQL Server 2017 still feels new to me, but SQL Server 2014 and SQL Server 2016 feel older. If I had to perform an emergency upgrade to an instance, I’d be more comfortable moving from 2008 to 2016 than 2017 right now.

    I wonder how many of you view the upgrades as more risky? These days the migration tools analyze for keyword issues, and many of those can be alleviated with compatibility levels. Perhaps some of you aren’t worried and will run your SQL Server 2008 instances until they die, only upgrading if forced. If so, let us know.

    If you’ve got R2 instances, however, please get rid of them. The sooner we get rid of this horribly confusing version name, the better.

    One late note, after this was written, Microsoft offer to add additional extended support if you migrate to Azure.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Figleaf Data Masking Beta

    I’ve been using the Redgate Software Data Masker for SQL Server in a number of situations to help customers. This is a tool we purchased in 2017 and is a part of the SQL Provision bundle to make building safe, secure dev and test databases.

    Project Figleaf is the next version of our data masking product and you can help us make it better. There’s a beta out that you can download and play with. Our development team is conducting research to better understand how we can meet your data masking needs.

    As much as I like Data Masker, it’s a clunky, cumbersome tool that takes some getting used to working with. The UI is old, and at times, a bit of an impediment. It works well, and I’ve grown used to it, but we can do better, and we’re trying.

    If you work with sensitive information in your production systems, don’t bring that back to dev and test. Instead, give our new Figleaf beta a try and see if this is something that might be helpful to you. Or even download Data Masker and try that.