Author: way0utwest

  • Starting to Use SQL Server 2017

    We’ll have a new version of SQL Server this year. If you missed the Data Amp keynote, in it Scott Gu announced the name as SQL Server 2017, which I assume means we’ll have installable RTM bits sometime this year. Maybe in June, maybe August, maybe later. In any case, there are some interesting changes coming, though not a ton. We will get a new platform (Linux) and certainly some nice improvements in a few areas, but overall a limited release. Given this will be a year or so after the last one, that’s not surprising.

    This rapid release cycle means that all of us will support more versions of SQL Server. I don’t know many organizations that wholesale upgrade all their servers. The last time I saw that at any size was in SQL Server 2000, and even then it was painful. Since then it seems many organizations will add some instances of new versions, but continue to support old versions. The more people I talk to, the more I think the ten year rule does exist in many companies. I met someone years ago that said their company (Fortune 100) expected any server installed to run for ten years. Period.

    That seems to be the case. Lots of people still have SQL 2005, or at least SQL 2008 instances. A few SQL 2000, and certainly newer versions, but a mix. Keep that in mind, as most of your companies will move forward with new work even as you support old server. This week I wanted to ask, when do you think you’ll have SQL Server 2017 in production.

    Realistically, when will you have a 2017 platform running a live workload. I don’t care how big or small, Windows or Linux, bare metal or in a container. When will you start to use resumable index rebuilds, graph structures, adaptive query processing or more? Will it be in 2017? 2018? For budget or other reasons, later than that?

    I’m at an interesting place. We still run SQL 2008 at SQLServerCentral, and it works fine. The site needs a basic relational system, though certainly some of the T-SQL changes in 2012+ would be welcome and make some code easier to write. The thing is, code is already written and most things work. We’re debating going to 2016, but I wonder if we shouldn’t just aim at 2017, get one more version ahead, and delay the next upgrade for another decade. I’m certainly tempted as most of the work we through at the database is simple relational work that really would run on SQL 2000 if it had to.

    Regardless of when you might upgrade, are you interested in doing so? Anything catch your eye in the new version? Or have you not even bothered to pay attention? All valid answers, and I’m interested in your view of the new platform.

    Steve Jones

  • A Couple Weeks until VS Live–Austin

    VS Live takes place in Austin on May 15-18, 2017. This is a great conference in a fun city. It’s a full stack event, with the change to learn about cloud computing, ALM/DevOps, SQL, and Visual Studio, all at the same event. You can move from room to room and learn about a variety of technologies.

    If you’d like to go, register with AUSPK14 and save $400 off the full conference price.

    AUSPK14

    I’m speaking, covering Database CI and SQL Server 2016 Security features, and there are plenty of other great speakers on the schedule. Come join us in Austin next month, have a margarita, and learn some new ways to build better software.

  • SQL Server on Linux is Just SQL Server

    I’ve been working with the SQL Server on Linux (SSoL) version for quite some time, almost a year. In all of that time, I’ve for the most part found that SQL Server is SQL Server. When I connect, run demos, check code, almost everything just works. If I didn’t bother to check @@version, this would appear to be just another SQL Server to me. That’s what a new video on Channel 9 shows as well. SQL Server is pretty much the same on both platforms. I’ve tested the Redgate tools and to all of them, SSoL is just SQL Server.

    There are some differences, which is to be expected. Any operations that access the file system and require paths work a bit differently, and for those people that end up administering the product, there will be some changes to get used to. The advanced HA features are similar, but again, some work is required. However, this isn’t all bad. I’m impressed with the apt-get process (I’m testing on Ubuntu), which is way, way easier than any patching or updating process I’ve gone through on Windows. In fact, setting up an Ubuntu VM last year was easy, and installing SQL Server was about as easy as it could be.

    The tooling on Linux isn’t as mature, and I don’t know when we will see a GUI client, but as I move more and more to PoSh or scripting to make changes in SQL Server, I expect more and more people to manage both Windows and Linux versions in the same way. Certainly using SSMS to write queries is a much nicer experience, and I would guess that many developers that might run SQL Server on OSX or Linux will want a Windows VM for SSMS. Of course, since Visual Studio is now on OSX, maybe we’ll see SSMS running natively on other platforms.

    I don’t know how many enterprises will run SQL Server on Linux, but I’m sure there are some that will. I don’t think a lot of organizations will move from Windows to Linux, unless they have loved SQL Server enough to install a single Windows host for the database and want to get rid of it now. I do think lots of developers will run SQL Server on Linux/OSX, especially in containers, where it is really easy to get a container running on their platforms.

    If you’ve experimented with SQL Server on Linux, or you are excited, let us know. If you think your organization might use this platform, let us know as well. I suspect a few of you will just because you can, which is as good a reason as any.

    Steve Jones

     

  • Limiting the Max–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    I was chatting with someone the other day about MAX() and how it can work within a set of rows, rather than across an entire result set. That’s a good query skill to have, so I mocked up a short demo. This will show the window functions in T-SQL, using the OVER() clause with MAX.

    Let’s build a table and add some data.

    CREATE TABLE counters
    ( countid INT IDENTITY(1,1)
    , countername VARCHAR(20)
    , counteryear INT
    , mycounter INT
    )
    GO
    INSERT dbo.counters
            ( countername
            , counteryear
            , mycounter
            )
        VALUES
            ( 'Test1', 2012, 1 ),
            ( 'Test1', 2013, 2 ),
            ( 'Test1', 2014, 3 ),
            ( 'Test1', 2015, 4 ),
            ( 'Test1', 2016, 5 ),
            ( 'Test1', 2017, 6 )
    GO

    If I now query, I will just use and ORDER BY clause in the OVER() clause. This will order all the rows from the result set by the year, and then apply a MAX to them.

    SELECT
        countid,
        countername,
        counteryear,
        mycounter,
        sumofallvalues = SUM(mycounter) OVER (ORDER BY counteryear),
        maxcounter = MAX(mycounter) OVER (ORDER BY counteryear)
    FROM dbo.counters
    ORDER BY
        countername,
        counteryear;
    

    The partial results are shown below. The important parts are the year and the sum/max values.
    2017-04-18 06_47_36-SQLQuery3.sql - (local)_SQL2016.NBA (PLATO_Steve (71))_ - Microsoft SQL Server M

    We see here that the counter increases by one until the last row. This is the data set, the year and counter increment. The max should be six, but it’s not six until the last row. Why?

    The answer comes from the framing of the rows. The OVER() clause, by default use a range of unbounded preceeding and current row as it’s set of values. In this case, with an order by on the counteryear, this means that when the query engine processes the first row, the entire set of values in the window is just the row with 2012. The next row has two rows, with unbounded preceeding being 2012 and the current row of 2013. This means for each set of rows, the range consists of previous values. I’ll show here what the counteryear values are for each row and the result of the max:

    • 2012 uses the 2012 row only – max 1
    • 2013 uses the 2012 and 2013 rows – max 2
    • 2014 uses the 2012, 2013, and 2014 rows – max 3
    • 2015 uses the 2012, 2013, 2014, 2015 rows – max 4
    • 2016 uses the 2012, 2013, 2014, 2015, 2016 rows – max 5
    • 2017 uses the 2012, 2013, 2014, 2015, 2016 rows – max 6

    This is a window that moves with the data, and is defined as being from the beginning of the result set to the current row.

    Let’s change things. I’ll add a second set of rows, and we can see here how this might differ.

    INSERT dbo.counters
     ( countername
     , counteryear
     , mycounter
     )
     VALUES
     ( 'Test2', 2012, 1 ),
     ( 'Test2', 2013, 4 ),
     ( 'Test2', 2014, 2 ),
     ( 'Test2', 2015, 8 ),
     ( 'Test2', 2016, 5 ),
     ( 'Test1', 2017, 11 )
     GO

    Now, let’s query again, but we’ll change our window. First, we’ll order by name for the MAX(), since that’s what we want to show. I’ll leave SUM alone. Next, I’ll change the window to be only the previous row and the current row.

    SELECT
     countid,
     countername,
     counteryear,
     mycounter,
     sumofallvalues = SUM(mycounter) OVER (ORDER BY counteryear),
     maxcounter = MAX(mycounter) OVER (PARTITION BY countername
     ORDER BY counteryear
     ROWS BETWEEN 1 PRECEDING AND CURRENT ROW
     )
     FROM dbo.counters
     ORDER BY
     countername,
     counteryear;

    Now the results are a bit different. My final ORDER BY ensures I have the tests separated. The first one looks similar in the max columns. I’ll explain the SUM in a different post.

    2017-04-18 06_55_24-SQLQuery3.sql - (local)_SQL2016.NBA (PLATO_Steve (71))_ - Microsoft SQL Server M

    The MAX() for test2 is different. Let’s see what happens here. Since my window is a ROWS clause, and it’s set for 1 preceeding and the current row, I get these values.

    Test2, 2012 row

    • Preceeding  – no values
    • Current – 1
    • Max – 1

    Test2, 2013 row

    • Preceeding  – 1 (2012 value)
    • Current – 4
    • Max – 4

    Test2, 2013 row

    • Preceeding  – 4 (2013 row)
    • Current – 2
    • Max – 4

    Test2, 2014 row

    • Preceeding  – 2
    • Current – 8
    • Max – 8

    Test2, 2015 row

    • Preceeding  – 8
    • Current – 5
    • Max – 8

    This shows that MAX  is limited to the frame I’ve applied to the window. The window is the OVER() clause, which in this case is the set of rows with the same counteryear value (the partition).

    Window functions get confusing and are strange, especially if you’ve spent most of your career without them and finding tricks to use COUNT(), SUM(), and other aggregates on subsets of rows. Things get easier in SQL Server 2012+, and you should spend time playing with small sets of data and understanding windows.

    SQLNewBlogger

    This was about a 15-20 exercise, but it was good since I needed to stop and think about how to use and show a window function and the ranges. Good skills practice.

    I’d like to see others explain this with a data set that they find interesting.

    References

    OVER() – https://docs.microsoft.com/en-us/sql/t-sql/queries/select-over-clause-transact-sql

    MAX() – https://docs.microsoft.com/en-us/sql/t-sql/functions/max-transact-sql