Voice of the DBA

Author: way0utwest

  • SQLServerCentral–Fixing the Time Zone

    One of the bugs features of the bbPress forum software is that all posts were shown in a time zone, which for us was a default of UTC. Not a bad choice, but this made for funny displays, depending on where you were. Posting in the UK showed you as having posted an hour ago after Daylight Savings Time. Posting in the US showed future times.

    A mess, for sure.

    It’s fixed, or at least, it’s mostly fixed if you’re a traveler. This fix rolled out while I was in Australia, and as a result, I logged in and my time zone got picked up as Sydney. That made sense, since that’s roughly where I was (Brisbane or Melbourne), but it made for some funny posts when I was back in Denver. I replied to a post yesterday and the time I was for the original post and my reply were both the next morning.

    There’s an easy fix for now. You can access your profile from the upper right menu. Once it comes up, click “Edit Profile” and then find the time zone. If it’s wrong, fix it and the posts will be at the right time.

    It’s something I wish we’d thought of early on, but in testing, we usually were looking for the posts in the right order, and I never considered if the actual time was the time I’d was working in. A mistake on my part, and my apologies for those in the community that were distracted, upset, or confused by this.

  • Practice Those Scripts

    I’ve written lots of scripts that were deployed to production. I’ve often had another set of eyes look them over, and still, we made mistakes. In fact, a recent Salesforce outage was blamed on a poorly written database script that gave users more rights than they should have gotten. There wasn’t an actual outage caused by the script, but since customers might have been able to see data and change from other customers, Salesforce took its own service down to prevent anyone from doing so.

    I’m a big fan of DevOps, and certainly including the database in a DevOps process to build a better software development flow. Part of that is ensuring that you can deploy by practicing the act multiple times. In a database world, this would mean that we run a script not just on a development server, but on a QA server, on a staging server, on any other environment we can find to practice and test the deployment. At that point, we should be confident of execution on the production system without issues.

    Good in theory, but sometimes you can’t easily test scripts in intermediate environments. I think changing security is a place where it can be hard to actually test things, especially if specific accounts are referenced that might not need or have access in that environment. Certainly some data changes might be easily be tested in intermediate environments, especially when these refer to configuration differences, like email or messaging systems.

    In this case, I suspect the “access changes” were data changes that updated values in certain tables in the Salesforce application. In that case, why wasn’t this tested? A restore of production to a staging environment would allow developers to test their script. It’s not multiple executions on intermediate servers, but it is better than nothing.

    I’m sure many of you have had the need to execute scripts to change data, alter permissions, or something else in production. Could the same thing that happened to Salesforce happen to you? What precautions do you take, or what would you recommend to prevent this type of issue. Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn.

  • Technology Flows Downstream

    A few years ago, I was listening a session on Azure SQL Data Warehouse at an event. At the time, one of the features I found fascinating was the separation of the storage from the compute portions of the service. We could load a lot of data in the system and pay for the storage, but we could spin up and down compute nodes to essentially scale out query processing to match our workloads. Azure Data Lake has something similar, and I was excited.

    I wasn’t excited about ASDW or ASDL because I don’t really use those platforms in my work, and I don’t have customers to talk to about those. I think they are useful, just not for me. I was, however, impressed with the technology, hoping that it would be coming in the next few years to SQL Server in the box and Azure SQL Database.

    It’s coming in SQL Server 2019, or at least, the start of it. We will get compute nodes, managed by Kubernetes, that will query other storage nodes that scale out I/O access. We also get this with Azure SQL Database in the Hyperscale edition, where there will be query servers and cache servers, designed to scale to infinite, or at least multi-petabyte, ranges

    I wasn’t always sure that the investments in Azure would pay off for the database side of things. It felt like Azure Stack was a natural place to help us manage and deploy SQL databases, and that the contained database work started in 2012 would get pushed by the needs of the Azure cloud, evolving and growing in future versions. We haven’t seen those pieces of technology grow, but I do think technology in other parts of the data platform has flowed to the “regular” OLTP database space.

    The separation of compute and storage really begins with the SQL Server 2019 era release, and I suspect that’s just the first step of how our SQL Server database systems will evolve in the future.

    Steve Jones

    Listen to the podcast at Libsyn.

  • Just a Week to SQL Sat Pensacola

    One of my favorite events, in a wonderful place to spend the weekend. I’ve been to Pensacola a few times (3?), including a couple times with my daughter. It’s always a fun weekend with Karla, Rodney, Ed, and the other organizers that make it a fun event. Even deep sea fishing Sunday if that’s your thing.

    This year I’m heading back after missing a few events. I’m lucky to go and I’m looking forward to delivering a new presentation. This one is one the future of Database Development with Containers, showing a vision of how things are changing. Microsoft has shown some similar items, but I’ve got some cool technology to show off from the Redgate Research Division, the Foundry.

    If you’re nearby, register and join me next weekend, June 29th, for SQL Saturday #884.