Voice of the DBA

Author: way0utwest

  • Getting Close to the 2017 RTM

    I still can’t believe that we’ll have a new version of SQL Server this year. After speaking at so many events last year, talking about the new features of SQL Server 2016, it seems crazy that there’s a new version coming out a year later. Welcome to the new world of DevOps, fast engineering processes, and the increasing pace of software releases from vendors. We can debate the wisdom or value of this, and you might not like it, but it’s certainly the reality of today.

    The first Release Candidate (RC) for SQL Server 2017 is available this week. The big change for RC1 is that we can now use Active Directory authentication on Linux, and we get SSIS on Linux. There are a few other items, but these are the big ones. I guess SSIS scale out is a big deal for some people as their data load times increase, but I’d think that is a relatively small number of people. I’d also be wary of having clustering support for my ETL workloads, all of which haven’t been designed for that environment. I would see this feature as being more important and valuable over time. For now, let the SSIS gurus develop some patterns and practices that make sense for us to follow.

    There are other new features in SQL Server 2017, and I’d urge you to play with them a bit. Upgrades are always tricky to justify for me, as I’m sure they are for you. If you don’t know how the new features work, or how they might apply to your systems, how can you decide what to do?

    I tend to favor sticking with what works for older systems and moving to new versions for newer systems. Your view might vary, and certainly unless you want to setup SQL Server instances on Linux, I’m not sure 2017 offers a lot over 2016. In fact, I’d accelerate any SQL 2016 instance installations I could to avoid being trapped with SQL 2017 licenses and the chance that price or licensing terms will change. If there were features that made significant advances for my current system, I’d certainly look at SQL Server 2017.

    Since I tend to only move to newer versions when there is a good reason or a new install is being performed, I like the rapid release cadence. With the deployment and testing in Azure, it seems to me the quality of SQL Server keeps increasing, and the rapid releases allow new changes to come out sooner rather than later. With a version every 18 months (my guess at the new pace), I can adopt new features relatively quickly if I think they are beneficial.

    That being said, SQLServerCentral still runs on SQL Server 2008. It works, and we really just would like a core database engine. I do find it strange to work on the 2008 version of T-SQL as some of the data analysis I try to do is harder to write. I’d really like to upgrade and hopefully we’ll make a good enough case to try and move to SQL 2017 late this year or next. Maybe then we can get the chance to play with some graph capabilities and add them to SQLServerCentral, comparing them to good old relational queries in real time.

    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.

  • SQL Server 2017 RC1 is Here

    And I’ve got it.

    2017-07-17 10_33_19-SQLQuery1.sql - 192.168.1.210.master (sa (52))_ - Microsoft SQL Server Managemen

    Glenn Berry posted a a link to the MSDN blog and almost immediately a note that the link was still the CTP. I decided to fire up my Ubuntu install and check. No updates there, though a few people reported Docker had the new bits.

    A short while later, the Windows link was correct, and my Linux update worked.

    I did re-register the repository

    curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server.list | sudo tee /etc/apt/sources.list.d/mssql-server.list

    And then the rest was the same as previous updates. Quick and easy, a few command line things to type and I was updated.

    Now I need to get Docker working, since I’m betting we’ll see updates and changes there faster than anywhere else.

  • PowerShell $env Variables

    I was playing with containers the other day, reading a Simple Talk article on the topic, and noticed the code in PowerShell (PoSh) used the $env:xx syntax for variables. I know I’ve seen this before, but for some reason this struck me as something I knew little about.

    I decided to search a bit. One of the first links was from WindowsITPro, and they had some great code: Get-ChildItem ENV:. When I run that, I get lots of information:

    2017-06-14 14_59_52-powershell

    There are more items, but there are some interesting ones that I think could be useful for me, especially with automation. I have a OneDrive path, my home path, the Username, and more.

    I know I’ll never remember most of these, but really I just need to remember one: Get-ChildItem ENV:

  • Short Names

    I started using computers a long time ago, and in the PC world, we were often limited to an 8 character name and a 3 character extension. Unix and MacOS allowed longer names, and many of us in DOS and Windows were jealous. Eventually Windows evolved, allowing long names, spaces, and really quite a bit of latitude in what you want to name a file. For example, try this and see what happens on your SQL Server:

    BACKUP DATABASE Sandbox TO DISK = 'Sandbox.thisisafullbackupthatIusetostartarestore'

    However, the three character extension still dominates, and many applications still use this. Microsoft has started to get away from this, as we have .docx, .xlsx, etc. Other vendors and software systems have started to expand names slightly. I was reading about the SQL Server Diagnostics Preview and noticed that the engineers will take a dump file (.dmp) as well as a mini dump (.mdmp) and a filtered dump (.hdmp).

    Now I know developers are lazy, and they don’t like to type, but in these days of auto-completion and other tools, why are we limiting ourselves. Why wouldn’t we use .minidump or .filtereddump as descriptive way of identifying the file? If we are no longer bound, why not include a better extension? I can’t imagine that the filesystem for many tools would be stressed by longer names.

    I’m assuming that people still feel bound to using the shortest set of letters that they think are unique, but with the growth of software applications from many, many sources, why not just be more descriptive? Would you want to see better filenames? I know I would.

    Steve Jones

    The Voice of the DBA Podcast

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