Author: way0utwest

  • Azure DevOps at the Data Platform Summit 2020

    I was lucky enough to go to the Data Platform Summit in 2017. I still have one of my favorite speaking pictures from the event:

    20800322_10213709692765472_429090589091695872_n

    I took my whole family and we enjoyed our time in India immensely. My wife asks me every year if we can go back.

    We can’t this year, as the event is virtual, like so many others. However the DPS team is working to put on another great event. There will be:

    • 72 hours of content, 2 Dec – 4 Dec
    • Pre-cons, 30 Nov and 1 Dec
    • Post-cons, 7 Dec – 8 Dec
    • On-demand access to recordings.

    All at a very reasonable US $109 Pre-cons are on sale for the next few weeks at $149.

    I’ll be talking DevOps and there are lots more sessions to choose from throughout the conference with chalk talks and open talks available as well.

    If you are looking for some late Q4 training, think about joining me at DPS 2020.

    If you’re looking forward to 2021 and dreaming, think about a trip to India. It’s a fascinating place, and I hope to go back next year.

  • The Challenges of Splitting a Table

    I ran across a discussion on Reddit about splitting a table. In this case, the original post had to do with a vertical partition of data, which is a technique that can help you better manage data in your database. However, I haven’t often seen this technique employed in the real world.

    I wonder how many of you have considered a vertical partition when you are modeling data. Often we may not think about this early in the lifecycle of an entity, but as it grows, you might think about reducing the amount of data you often query in some way, and a vertical partition can help.

    Is there some criteria that you might use in deciding this? Or how you can evaluate if there is a need? I once worked on a system with a very hot table, lots of queries, lots of updates against this table from our online system. In response to some requests, the developers wanted to add some columns to the table. This was important, and we needed to capture the data.

    These were valid columns, but they were large in terms of data size, and not every one would always be used. This was before the option of sparse columns, so that wasn’t an option. I had no interest in an EAV table, despite the fact that it might have worked well at this scale. Instead, this was a situation where I thought a vertical partition would work. In fact, I thought a few of the other columns in this entity could be moved as well, as they were rarely queried and contained significant data.

    We split the table, and performance actually improved for the main table, as it had less data. Just like an index, we had more rows on every page and less IO for range queries, and even key lookups for data that wasn’t already indexed.

    There are lots of good techniques in database development for dealing with the challenges we face in data modelling and with performance. I’d urge you to learn about some of them and understand when they can be useful. I would also practice implementing them, making changes to existing tables, and learning how you can deploy them if the need arises.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Daily Coping 15 Aug 2020

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here.

    Today’s tip is to avoid saying “I ought to” or “I should” to yourself.

    My wife has reminded me of this for years, to avoid using “should” as it is a cognitive, or thinking, trap. I remember this every time I hear myself using should, either to others or to myself.

    As a result, I’m working to either decide to do something, or to let it go. I might drop it on a list for later, but I’m trying hard to not say I should do something. Do it or don’t.

    I’m better at this with home projects and chores. I don’t try to set myself up with an excuse. I’ll just tackle something or defer it with certainty.

    I still have work to do here with my job. I have too many “I should do xx today” conversations with myself.

  • Adding ApplicationIntent=readonly to SQL Data Compare

    Recently someone asked a good question about SQL Data Compare. How can they add applicationintent to the connection?

    If you are using Data Compare, and you are reading from production systems, load is a concern. With Availability Groups (AG), we can point SQL Data Compare to the secondary replicas and limit the load on the writable primary. How can we do that? Well, it’s actually easy.

    We have a doc page for encrypted connections, and we can use the same type of action to work with AGs.

    In a new project, I typically see something like this:

    2020-09-04 12_04_43-New project_

    What I can do is edit the server connection on the right. Just click in there, and then add this:

    Aristotle\SQL2017;applicationintent=readonly

    This will add the option in the connection string.

    2020-09-04 11_51_37-New project_

    If I open the project file, I will see the XML, where I can also edit these connections if desired.

    2020-09-04 12_09_42-E__Documents_SQL Data Compare_SharedProjects_(local)_SQL2017.SimpleTalk_1_Dev v

    I can do this for any of the options I need for connection strings.