Voice of the DBA

Tag: T-SQL Tuesday

  • T-SQL Tuesday #148–User Group Advice

    tsqltuesdayThis month the T-SQL Tuesday invitation is from Rie Merritt, and it’s one that means a lot to me. I don’t actually run a user group, but I think community is important. It’s a big part of my job and my life.

    Rie asked me if she could host this month because she had a specific topic. If you’d like to host a T-SQL Tuesday, all you need is a blog and participation in another month by writing a post. You could even write a post today for T-SQL Tuesday #1.

    If you’re interested, contact me.

    Advice for User Groups

    As I mentioned, I don’t run a group. In fact, I never have, but I have run events, attended lots of meetings, and I do speak at quite a few.

    The pandemic has been hard on many groups, and a blessing to others. While I don’t like the virtual meetings, I understand how and why they work for some groups and not for others.

    My big advice for organizers is twofold, and I’ll write a couple paragraphs about each.

    Serve Your Community

    My main advice is that your work with groups or events, whether leader, speaker, or something else, you ought to make sure you are serving your community. What is best for them, or what do they want?

    Sometimes I find leaders doing what’s best for them, without knowing what the community might prefer. If you want virtual meetings for your own personal reasons, whatever they are,  make sure a large portion of your attendees and speakers agree. Same for in-person meetings. If your area wants to stay online, understand that.

    This isn’t to say that you can’t experiment, and that you might make decisions on days/times/etc. More it’s advice to think about what helps people as we come out of this pandemic.

    Go Slow

    I’ve seen a lot of groups struggle over time to run a monthly meeting and find speakers. Speakers are easier online, but it’s still work.

    My advice is that you can consider doing something less than monthly, especially if you move to hybrid or in-person. A quarterly or every-other-month pace might suit you (and others better).

    Also think about adding in some lunch meetings, perhaps just discussion ones without a presentation. Bond, be social, just talk, vent, and share what we love about data and technology.

    Don’t kill yourself. I’d prefer you enjoy running a group for 3 years than burning out after 6 months.

  • T-SQL Tuesday #147 Wrap-Up

    I was the host this month for T-SQL Tuesday #147 and here is a look at the people who blogged (that I know about). If I’ve missed anyone, let me know.

    Rob Farley wrote about updates, not only with version upgrades, but also CUs and the need for automated testing.

    Deepthi Goguri talks about her first job and the requirement to move off SQL Server 2000. This was after her schooling was on SQL Server 2012. I like the emphasis on fear as a reason not to change, and the use of tools to find potential problems that could occur during the upgrade.

    Kevin Chant writes that he uses upgrade events as chances to improve the way a system works. He also uses the Data Migration Assistant to move, but do so carefully. Don’t jump across too many versions.

    Damien Jones asks us if we can avoid upgrades in the cloud. That’s an interesting perspective, and one I don’t see often. It is legitimate, as every time something changes, we need to test, and if there are issues, what do we do? Avoiding change is something that I find important in the short term but highly detrimental in the long term.

    Greg Moore writes about the challenges of convincing a client to upgrade.

    Glenn Berry gives us a way to make a case for upgrades, working against those that don’t want to change, and some thoughts on related tech changes that might help you decide to upgrade.

    Marcin Gminski talks about https://sqlwatch.io/blog/t-sql-tuesday-147-sql-server-upgrade-strategies/

    Alex Stuart notes that if it isn’t broken, why fix it? Don’t upgrade for no reason, but there are some reasons to upgrade and Alex lists them.

    Reitse Eskens gives us a basic process to follow when upgrading. These aren’t detailed steps, but these are the things I look at when upgrading.

    Gethyn Ellis talks about why we wait to upgrade and why we might rethink that.

    The first upgrade, from Todd Kleinhans, looks at the problems he had an how we got past an Access to SQL Server upgrade. I’ve been in this exact situation, back in the early 90s. It was a mess and very stressful, but I learned a few things. Including to avoid Access for years.

    Lastly, but not least, Martin Catherall provides some general thoughts on how he would approach an upgrade, with some tool suggestions to help.

  • T-SQL Tuesday #147 Invitation – Upgrade Strategies

    tsqltuesdayIt is time for T-SQL Tuesday #147 and this month I get to be the host. Since I’m in charge, I usually try to ensure I remember what this is like and host every year or two. This will be my sixth time hosting. The others I’ve hosted are: 013, 027, 106, 117, 137.

    For this month, I was thinking about SQL Server 2022. The next version of the platform was announced in the fall, and I’ve spent a little time working with it, getting familiar with some of the changes. I don’t plan on upgrading SQL Server Central anytime soon, but you never know.

    Planning for Upgrades

    In my career, most of the time we don’t upgrade production databases very often. In most of my jobs, we’d change versions for new databases, but existing ones often lived on their original version. It’s how I got into a job where I was managing 4 different versions of SQL Server. These days I expect it’s common for many DBAs to have to deal with that many, or more, versions.

    I do have customers these days that try to upgrade often, and limit the number of versions they work with. I have customers now that are on a mix of 2016-2019 only, some that might be working on 2014-2016 only, and I’ve run into a customer that only has SQL Server 2017. Of course, they have few databases and look to upgrade about every 5 years when mainstream support is running out for their edition.

    This month I want you to write about how you look at SQL Server upgrades. A few things you might think about:

    • Why we wait to upgrade?
    • Strategies for testing an upgrade
    • Smoke tests or other ways to verify the upgrade worked
    • Moving to the cloud to avoid upgrades
    • Using compatibility levels to upgrade an instance by not a database.
    • Checklists of things to use in planning
    • The time it takes to upgrade your environment
    • What you evaluate in making a decision to upgrade or not?
    • Anything else

    I don’t know when SQL Server 2022 will release, but certainly many of us will need to consider in 2023 whether we want to upgrade systems or not. Think about it and write about something that matters to you.

    The Rules

    Write your own post in response to the invitation. If you want to be in the wrap-up, follow these rules. If you read this after Feb 8, 2022, just write your response on your blog.

    • Write your post and publish it on Feb 8 ,2022, UTC time
    • Include the T-SQL Tuesday logo and link to this post.
      (logo in this post)

    • Ensure you leave a comment on this post with the URL of your post (or a trackback/pingback)
    • Publicize your  post on Twitter/LinkedIn with the #tsql2sday hashtag

  • T-SQL Tuesday #146–Changing Preconceptions

    tsqltuesdayIt’s the start of a new year, and the first T-SQL Tuesday is from Andy Yun. I’ve known Andy a long time and this is his third time hosting with a creative prompt for us all to consider.

    I really like this one as it could be taken as a technical or a non-technical prompt. What did you think was one way and you learned it was another way. Always good to stop and double check that your view is actually representing what you think.

    We all do this in our views of life as well as work, and it can be hard to change what or how we think. This is especially true for many of my customers, as I find them wanting to adopt DevOps, but not really wanting to change.

    I’ll tackle this one in a couple ways, one technical and one non-technical.

    Separate Accounts for Each Instance

    For a long time, I always used separate domain accounts for each SQL Server service. Even in a large environment, with hundreds of instances, I did the work (or have junior DBAs do it) to ensure that each service was account separated. This was important because I’ve had change passwords and other issues break services in the past. None of the incidents seemed worth saving a bit of time to set up separate accounts.

    Over time, and as SQL Server evolved, Group Managed Service Accounts came into being. I resisted using these at first, but over time I’ve realized that these are valuable and provide security as well as ease of administration. If I went back to managing servers, even single ones, I’d likely look to ensure that gMSA was the standard.

    Take Feedback as An Opportunity

    I’ve struggled with having someone criticize me for my work. I’ve even struggled when they suggest something else, bristling at the idea that I wasn’t doing something well. Often I was successful and doing something well, but there might be a better way.

    Across time, and age, I’ve learned to appreciate other points of view and not become defensive to feedback. Instead, I’ve started to look at other views as a chance to learn or grow, or even just try something. I can still reject the advice or suggestion, but I ought to consider it.

    I’ve started to adopt the “strong opinions, loosely held” philosophy at work.

    Note, I’m trying to do this in my personal life, but I still very much suck at this.