Author: way0utwest

  • The New CU Schedule

    Is my math right? The new CU servicing schedule for SQL Server 2017 is:

    • 1 CU per month for the first year
    • 1 CU per quarter through mainstream support (5 years)

    That means by my count, we get this:

    WITH myTally(n)
    AS
    (SELECT n = ROW_NUMBER() OVER (ORDER BY (SELECT null))
      FROM (VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10)) a(n)
       CROSS JOIN (VALUES (1), (2), (3)) b(n)
    )
       SELECT dt = CAST('20171002' AS DATE)
       , patch = 'RTM'
       UNION
    SELECT dt = DATEADD( MONTH, n, CAST('2017-10-02' AS date))
        , patch = 'CU' + CAST(n AS VARCHAR(2))
    FROM myTally
    WHERE n < 12
    UNION
    SELECT dt = DATEADD( QUARTER, n-13, CAST('2018-10-02' AS date))
        , patch = 'CU' + CAST((n -1) AS VARCHAR(2))
    FROM myTally
    WHERE n >12
    AND n < 30
    ORDER BY dt

    Or, for those of you want want it spelled out:

    2017-10-02 RTM
    2017-11-02 CU1
    2017-12-02 CU2
    2018-01-02 CU3
    2018-02-02 CU4
    2018-03-02 CU5
    2018-04-02 CU6
    2018-05-02 CU7
    2018-06-02 CU8
    2018-07-02 CU9
    2018-08-02 CU10
    2018-09-02 CU11
    2018-10-02 CU12
    2019-01-02 CU13
    2019-04-02 CU14
    2019-07-02 CU15
    2019-10-02 CU16
    2020-01-02 CU17
    2020-04-02 CU18
    2020-07-02 CU19
    2020-10-02 CU20
    2021-01-02 CU21
    2021-04-02 CU22
    2021-07-02 CU23
    2021-10-02 CU24
    2022-01-02 CU25
    2022-04-02 CU26
    2022-07-02 CU27
    2022-10-02 CU28

    There will be slippage, and potentially other issues, so I don’t know we’ll see 28 CUs, but having a schedule is something I’m glad about.

  • Get-DbaPowerShell

    When I first saw PowerShell, at TechEd 2006 (ish) and I was enamored. This was a much better environment than VBScript for working in a shell. Then I realized I needed -eq, -gt, etc. and was less excited. These language elements felt like a step back. Then I tried to build a restore script for SQL Server databases early on and was much less excited.

    Across the years, I’ve played with various tasks in PoSh as opposed to T-SQL or simple command scripts in various languages, and I find myself going back and forth. PoSh is very useful in some ways, more cumbersome in others, and I still am not sure exactly how I feel about it as a go-to tool. I am coming around to use more PoSh because of the dbatools project, and I find myself considering PoSh instead of T-SQL, especially when I think I may want to work across instances and string together commands.

    I was quite excited recently by T-SQL Tuesday #94, hosted by Rob Sewell. The topic was PoSh, and quite a few people participated, as you can see from the Get-PostRoundup. There are some creative uses of PoSh, such as importing Excel data, administering SSRS, turning Azure VMs off, cleaning up orphaned files, and more. Personally, once you start to use Azure more, PoSh makes the portal seem cumbersome and slow, and I find that for recurring tasks, it’s a much better tool.

    Recently I saw the DBAfromtheCold write a short piece on why you should learn PoSh. It’s a good look at some of the tasks that are easy through PowerShell. Some of these could be done in T-SQL, some with other scripts, but PoSh certainly is a possibility and an easy way to manage some of the tasks you might need to do at scale.

    I don’t think PoSh is the best way to do everything. In fact, I often still lean on T-SQL for many admin things, especially if I already have a connection open in SSMS. However, as I learn more about PoSh and how to use it, I can make those judgment calls about when it’s a better fit. That knowledge helps me become a more capable and stronger data professional, because I have choices about how to work with systems, and I have some knowledge or basis for the decisions I make.

    I advocate continuing to learn throughout your career, and certainly including PoSh as a topic if you work on the Microsoft platforms.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Test Your SQL Memory Setting with dbatools

    I really like the dbatools project. This is a series of PowerShell cmdlets that are built by the community and incredibly useful for migrations between SQL Servers, but also for various administrative actions. I have a short series on these items.

    One of the settings that has caused me problems at times is the max memory setting for a SQL Server. Overall, I like to have dedicated hosts for SQL Server and may not care about limiting SQL Server in way way. However, there are places where I may have multiple instances, or other applications, and I should be setting memory to some level.

    Jonathan Kehayias wrote a post about calculating max memory, and that was the inspiration for Test-DbaMaxMemory. This is a great little resource that you may use rarely, but it saves some time and makes the memory check quick and easy.

    It’s a simple command, with a parameter for the instance. The Format-Table is a great place to pipe this output. For one of my instances, I see:

    2017-09-28 13_29_48-powershell

    Not great, since I have other instances running. I wouldn’t want this to take over my workstation. My other instance is a little better configured.

    2017-09-28 13_30_38-powershell

    There are all sorts of filters here to use with this. The doc pages shows filtering to find instances where the setting is greater than total  memory. Maybe a better one might be looking for instances greater than (total memory –2GB), or 4GB. Or maybe you want some deviance from the recommended value.

    You can run this with any list of servers as well, and get a nice report. Maybe even one that you can use to convince your boss that you need a bit more RAM for that busy instance.

    As with the other dbatools, this fulfills a simple function. It’s quick, easy, and helpful. Give it a try today.

  • This Made Me Laugh: SQL v NoSQL

    It’s a humorous history lesson on SQL (and product promotion), but it opens like this:

    battle

    SQL awakens to fight the dark forces of NoSQL

    From there it looks at the beginnings of SQL and the growth of NoSQL, going through a few sections, like

    newhope

    Part 1: A New Hope

    and

    strike

    Part 2: NoSQL Strikes Back

    before moving to

    return

    Part 3: Return of the SQL

    They finish with the idea that SQL is the most important, and common, tool for data analysis. In this era of Python and R, many may disagree, but I think they’re overall right.

    Perhaps this last part proves that?

    yoda

    Master Data Scientist Yoda

    It’s an interesting read, and I may have to watch some Star Wars this weekend.