Tag: administration

  • Index Maintenance Can Change NORECOMPUTE Settings

    I had a customer recently ask about a change in one of their constraints on production, where a new option appeared when they went to deploy some changes from QA. They asked how this could happen, and I’ll show how in this post.

    Suppose I create a table like this in a development environment.

    CREATE TABLE [dbo].[Logger](
         [LogID] [INT] NOT NULL CONSTRAINT LoggerPK PRIMARY KEY,
         [LogDate] [DATETIME] NULL,
         [LogMsg] [VARCHAR](2000) NULL
         )
    GO

    I (hopefully) have a process to get this to production (version control, automation, etc.). Once in production, if I were to script this on SQL Server 2022, I’d get this from SMO.

    CREATE TABLE [dbo].[Logger](
         [LogID] [INT] NOT NULL,
         [LogDate] [DATETIME] NULL,
         [LogMsg] [VARCHAR](2000) NULL,
      CONSTRAINT [LoggerPK] PRIMARY KEY CLUSTERED
    (
         [LogID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
    ) ON [PRIMARY]
    GO

    This looks different, but really this includes the defaults that existed in dev, and also in production. Hopefully all my SETtings and configuration is the same, to ensure no surprises.

    Now, let’s imagine a DBA has some index maintenance, perhaps Ola’s scripts or some other script that works through all tables and indexes. If a DBA decides they’d like to edit the script to change a setting, they might end up running this code for my Logger table:

    ALTER INDEX ALL ON dbo.logger
    REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON);

    There’s a small change in here from the defaults, which I’d see if I were to run a SQL Compare comparison. Now I’d see this type of change, which might not be a problem, but it might be an issue where each deployment wants to reset this setting.

    2025-04_0139

    If you don’t think this is a big deal, here’s the deployment code:

    2025-04_0140

    I would not want this going through my deployments. And it might if our team were no diligent in looking at the deployment script.

    Be explicit with defaults, and be careful about making changes in production. You might end up creating problems in your update process if you don’t feed these changes back to development.

  • Part-Time DBAs

    Some of you reading this are database administrators (DBAs) who manage systems as their full-time job. Others of you might be developers, analytics people, or someone else who has another job, but you get stuck with managing the database somehow. I’ve seen a receptionist and a dental hygienist act in this role. We may call you the accidental DBAs, though that doesn’t imply you are good or bad at managing databases. I got into this line of work as an accidental DBA who was also a developer.

    No matter what your job title, my guess is that you aren’t over-staffed at your organization. Likely you wish you had one (or more) more person to help keep up with the work. It seems that we never have enough time to get everything done in a week. And that’s with a full staff. What do you do when someone is sick or goes on vacation? If you’re like me, you get further behind and feel extra stress while your coworker is out of the office.

    There is another way, and I thought this piece had a great title: Having a Part-time Database Administrator Can Help Improve your Bottom Line. It’s from DCAC, a consulting company that provides remote DBA services. There are other companies like this, such as Procure SQL, Straight Path Solutions, Dallas DBAs, and more. All of these companies are available to help augment or relieve pressure on your staff.

    The piece makes a good argument that often your staff is busy and might not have some of the specialized training or advanced skills that might help solve complex performance issues, architect HA solutions, perform cloud migrations, and more. For many companies, it can be hard to acquire these types of skills, and even if you have a plan, it can be expensive. What if your expert is out of town when you need them. What if you train them and they leave? I believe in training people, but I also know that you have to be able to augment your staff at times.

    Using trusted partners to help you improve parts of your business is something companies do in many ways. We might employ a handyman, but would still hire an outside plumber for some work, especially if it is a large job. Why not do the same thing with your technical staff?

    These companies might seem expensive when you look at their rates, but using them part-time, in strategic places, can often help your bottom line.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Monday Monitor Tips: Looking Back in Time

    Often we find out about a problem reported by a customer after the incident has passed. This might be from a trouble ticket or even an email that we didn’t see until a period of time has passed.

    How can we look back at the activity of a server in the past? This post looks how a DBA can time travel back to a situation that occurred in the past.

    This is part of a series of posts on Redgate Monitor. Click to see the other posts

    Time Traveling

    Let’s imagine I get a ticket that said there was a problem at 2:15am from a user running a process. I didn’t get to this at 2am, but at 9:15am when I receive it, I need to look back at what was happening.

    If I pick a server in Redgate Monitor, I’ll see the view below. This is of the staging02 server on monitor.red-gate.com. By default, this shows me the last hour of activity on the server.

    2025-03_0085

    In the upper right corner, I can see the time frame selected on the left (below) and the amount of time. I’ve selected the drop down, and there are many other choices. I also see the metric time at the top, just in case, I’ve started to mess with other values.

    Note: there is a calendar control to the left that can go back to previous days if you don’t want to use the time duration drop down.

    2025-03_0086

    In this case, let’s jump to the last 12 hours. If I select that, you can see my display changes a bit, zoomed out to show 12 hours not 1. The four charts below haven’t changed, however.

    2025-03_0087

    Most of the top chart has a darker background, except for a portion at the far right, which has a white background. This white background part is the focus window, and it determines what the 4 graphs below show, as well as the query information and other data.

    This is set to 1 hour, but I can expand it. If I drag the box on the left side of this further to the left, I can expand the amount of time shown. If you look below, I’ve expanded this to 7:37am as the start.

    2025-03_0088

    I can also slide this. I’ll slide this to the left to cover to 2:00am-3:00am part of the graph. Now I see different views below in the four graphs.

    2025-03_0089

    In this case, I now can focus on the 2:00am issue. I see an annotation that there was a Flyway deployment at 2:00am. You can see the annotation zoomed in with the tooltip when I hover the mouse on this icon.

    2025-03_0090

    I can scroll down to the query area, and I see the top queries, of which there were just a few.

    2025-03_0093

    The top one has a lot of duration, and if I expand it, I can see the query history. Note there was a query plan change just after 2:00, when my deployment occurred. The duration went up and then started to slightly drop. I see another plan change at 2:40am, and if I were to look back at the top, I’d see a second deployment from Flyway at that time.

    2025-03_0095

    I don’t quite know what changed in the deployment, but I’d start looking here to see if this affected my query.

    Summary

    The focus window in the overview for an instance allows you to set the time frame in which you see data related to that instance. This lets you time travel back to look at the server as it existed in the past. The amount of time you can travel back depends on your data retention settings, which we’ll examine in another tip.

    Hopefully this gives you a quick tip on how you can focus your efforts to a relevant period of time when you get an issue to review.

    Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

  • Tracking Table Sizes

    Managing a production database can be a challenge for many reasons. However storage growth has been one I see often as causing issues. From full logs to filled disks, it seems that we can struggle with dynamic workloads where we have no control over who can add data to systems.

    Many DBAs have some sort of alert set on data files or disks, but even with those alerts, an unexpected load or runaway query could still fill a disk. I know I’ve been called back into the office because some business person decided to load an unexpected amount of data. In fact, more than a few times someone thought their load didn’t work for some reason and repeated loaded a large amount of data, filling a disk or log file.

    Recently, I had a customer ask about tracking table sizes daily in their databases. They were looking to watch table growth. Another person dismissed this as not valuable, which was interesting to me. I’ve done this in the past, and I’ve found it valuable. No knowing the size every day, but having an idea of the growth factor. I didn’t keep this data long, usually a week rolling older data off as I added more. That was enough for me to trend how quickly a table was growing.

    This also allowed me to set an alert if there was unusual growth for a table, and often track down a potential issue quickly. Either I’d realize our workload changed and tables were growing faster, or I could debug a sudden growth issue down to some sort of data load. Often I could catch an issue before I received an alert (or phone call).

    I wonder how many of you track table sizes and if you find it beneficial. Is this something that helps you better understand your system or is the total size of the database good enough.

    Or maybe you have so much storage allocated you don’t worry about space. Lucky you.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.