Voice of the DBA

Tag: administration

  • Upgrading SQL Server Central

    The decision to upgrade database servers can be a complicated one that involves features, costs, and support requirements. While I think many people would love to run database systems for ten years, often there are concerns about support, which effectively ends after five years for SQL Server. While you can purchase extended support, is that worth the cost? A hard question to answer, but one I’ve had to confront lately. When do you upgrade a database instance?

    I’ve discussed this with a few customers, but it also came up in the context of SQL Server Central. We run a SQL Server 2016 database on Windows Server 2016. Someone recently sent a note that since 2016 is out of support, they’d like to upgrade the systems. They were thinking SQL Server 2019 on Windows Server 2022, but with the release of SQL Server 2022 that doesn’t make sense.

    I want to defer this process as long as possible. To me that means always aiming for the latest and greatest version. SQL Server releases roughly every 2-3 years, so this is the best time to upgrade for us. If we can upgrade before 12 months, we get 4+ years before we revisit this topic. If we were to upgrade to SQL Server 2019, then we’re already down to 2 years of support before we need to consider the topic again.

    I think many DBAs would feel the same way, looking to test and certify SQL Server 2022 for their internal apps. This is one reason why getting the RC0 and RC1 releases of new versions for some initial testing make sense. The sooner you can upgrade in version’s lifecycle, the longer before you do it again. Of course, if you have more than 50 servers, you might just be upgrading every year anyway, as some system is always falling out of support.

    Upgrades take time. There’s the time considering the decision, the testing a new system, the actual upgrade time, whether in place or migration, all of which eat up labor and time. Doing this for more than a few servers can become a full time job in some cases. That makes me start to really see the wisdom of using a PaaS service that’s evergreen.

    For organizations where support matters, then upgrades are a fact of life and a regular occurrence. However, if formal support isn’t an issue, you might feel differently. The more mainstream you keep your feature usage, the more likely that you can go far past 5, or even 10 years, with your database system. I know there are still companies running 2008, 2005, and even a few 2000 servers. I don’t know that the SQL Server Central code would run on SQL Server 2000, but it might. Project Nami is using fairly generic SQL. If we were more concerned about database licensing, likely we’d have not upgraded the site from ASP.NET to WordPress.

    For now, I think we’ll likely upgrade sometime in early 2023. I am not worried if things are delayed, but I do know that we also want to upgrade both WordPress and PHP. There is an order to getting all these steps completed with OS and database upgrades. Because of this, I want to ensure that we proceed soon and get things moving while my schedule is fairly light so that I can test and deal with any issues that arise. Hopefully there won’t be any, but I’ve learned to hope for the best and prepare for the worst, especially with software upgrades.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • T-SQL Tuesday #157–The End of Year

    tsqltuesdayIt’s that time of the month, and I’m late. I’ve been on holiday for a week, so this is a quick post for T-SQL Tuesday. This month is hosted by Garry Bargsley, and is a fitting topic for the last month of the year.

    Garry asks about end of the year data activities. Most of his examples are administrative, but I’m sure there might be some dev activities as well. I’ve got a few thoughts on each, some of which I’ve done, some of which I wish I’d have done in the past, but recommend now.

    T-SQL Tuesday is a great place to participate in the community and a great way to show your knowledge and skills off as well for potential employees. Write your own posts on a blog, or somewhere like LinkedIn, Medium, or another site. If you want to host, ping me @way0utwest or sjones at sqlservercentral dot com.

    End of Year Administration

    When I’ve been in the Operations side of data, there aren’t a lot of things I do at the end of the year, but I do find the downtime useful for some maintenance and cleanup. Usually we are doing well reactive stuff as business slows down, so I spend time on things that I’ve wanted to do all year, but haven’t had time to tackle.

    The things I try to do:

    • Index cleanup – look for dups, unused, etc.
    • archive/delete data or tables – I try to clean data where possible. Less always makes things faster
    • Chronic issues – Think about how I can solve something and prevent future problems
    • Space planning – look over trends and be sure we’re ready for next year.
    • Security – remove old accounts (or disable) as much as possible.

    End of Year Development

    Development tasks tend to be more tightly specified, and there often isn’t a good end of year list. However, similar to administration, one thing I have tried to do when times are slow is tackle things I’d want to change, but never have time. End of year is like this, as are some times after deployments.

    Apart from code I might want to refactor or change, the big things I might look at during the end of year are:

    • Branch cleanup – easy to have some of these hanging around.
    • Pipelines – Use time to improve these, or ensure that they are noisy. Either change something, reduce tests, or try to avoid any unnecessary things causing the pipeline to go red.
    • Learning – covered below.

    Bonus – End of Year Career

    This isn’t specifically for SQL Server, but it could be. This is a good time of year to stop and try to assess how things went. It’s also good to look forward, and use slower times to make the future better. A few recommendations:

    • Always have a list of things to read/learn/practice. Use slow times to work on something. If nothing else, tackle the Advent of Code.
    • Assess your career – is this the place for you? The job, the employer, the field? Think about what things excite you and what don’t, what make days drag, or go by quickly.
    • Plan for the future – Make a few career goals. I’ve done this for a few years, and it helps me continue to learn and grow.

  • Assembling Your Own Toolbox

    Last month Brent Ozar posted that September was community tools month. He had a number of posts that highlighted tools and a number of other people (Francesco, Erik, VladDBA ) did as well. I didn’t do any blogging because, well, it was a busy month for me. I was gone from home for 21 days, so a bit harried in life.

    As a part of this effort, I saw Ken Fisher write about being a Script Magpie, which is an interesting analogy. A magpie is a bird that collects various shiny objects. Ken collects scripts in the same way. Things that catch his eye are added to his repo of scripts that he keeps handy.

    I used to do something similar. I didn’t have a repo back then, though I should have. However, all VCSes in the past lacked some of the ubiquity of Git. Instead I had a folder that I kept synched on various flash drives that I carried from job to job. I’ve also usually had a share inside companies where a team of developers or DBAs could share SQL scripts.

    I’d hope that most technology professionals would share scripts, especially when they can be tokenized or added as SQL Prompt snippets. Reusing work is a big part of working with computers and why many people have embraced tools and utilities that they didn’t write themselves. I certainly think having a toolbox is important, especially tools that integrate well with an existing environment.

    I don’t think it’s worth rewriting many tools inside a company. I work for a software vendor, and I’ve seen the effort put into building tools. Both free and paid tools can save you a lot of time and effort inside your job, not the least of which is maintaining the tools over time as versions and editions change.

    What are the contents of your toolbox? Which things are those that you’d bring to a new position if you moved organizations or groups? Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Checking Database Compatability = #SQLNewBlogger

    Recently I needed to check the compatibility level of a database and SSMS didn’t work. This is what I did in T-SQL.https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-ver16

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBRloggers. Here are some hints to get started.

    Querying the System

    I would have assumed I could use the DatabaseProperyEX() function to get this, but as I look through the list of properties, the compat level isn’t in there.

    When I look through the Docs for the compat level, I find that the page for database compatibility, the page mentions that querying a DMV is the way to check this. Seems strange, but I guess that’s what you do.

    Here’s the query:

    SELECT name, compatibility_level FROM sys.databases;

    Y0u can filter this by database name if you need it.

    I needed this as I was testing SQL Server 2022, but my SSMS version (18.10), didn’t recognize level 160. I assumed that was what should have been there, but I needed this query to verify.

    Now, hopefully I’ll remember that I just need to query the DMV.

    SQL New Blogger

    This was a quick post, really just over 5 minutes to write. It’s not super technical, but it does show that I can research something and solve a problem. And I have an alternative when my main tool doesn’t work.

    Good skills to showcase on a blog.