Tag: syndicated

  • T-SQL Tuesday #187–Solving Problems

    This month we have a great invite from Joe Fleming, a first time host of T-SQL Tuesday. Joe reached out when I requested some hosts and I’m glad he did. He’s got a great challenge for people and I’ll answer in two ways, for work and non-work.

    I manage the T-SQL Tuesday site and I’m always looking for hosts, so if you want to host one month from your blog, send me a note on Twitter, Blue Sky, or at SQL Server Central.

    Troubleshooting SQL Server

    In my career, I’ve had all sorts of issues come up. Here’s a description of one of the stranger issues. This isn’t the exact issue, but it was similar to this.

    A user reported they couldn’t log into the server. They were logged on earlier, but can’t connect now through an application. What could be the problem?

    When looking at this type of issue, I usually think there is some sort of network issue here, or perhaps a service issue. My  thoughts are:

    • Can I connect? Or can others? (trying to determine if it’s this user)
    • Can this user connect with another app that might give an error message?
    • Is the server instance up? (check the basics and isolate if this is networking)
    • Has this login had a change to permissions/password/etc. Perhaps an AD change.
    • Has something else changed on the server?
    • Has something changed on this user’s machine?

    At some point, I’ll isolate where the issue is and determine how to fix it. In this case, I managed to determine the user was a DBA that was playing with a logon trigger and locked themselves out.

    The UTV Won’t Move

    On the ranch we have to learn to handle lots of things ourselves. YouTube has been a boon, but it’s also a bit of common sense and problem solving that we need to get things done. It can be hard to get people out to the ranch, especially for small things.

    Sometimes big things.

    Awhile back I came back home from a trip to find the spare UTV we have in one of the fields. I asked what had happened and a kid said that it died.

    That’s not a good description, so I asked how it died. What was going on? what was happening? This kid said they’d stopped the vehicle to do something and put it park. When they went to shift into drive, it wouldn’t move.

    Did the engine run?

    Yes, but the UTV didn’t move.

    Now that I had a better story, I could debug further. I knew that it ran and went out to start it myself. Sure enough, it starts and the shifter didn’t do anything, but it felt loose.

    Sometimes hands-on helps. I knew immediately a cable had broken.

    First thing, get this out of the field. I knew there was a way to shift it without the cable, I just had to figure out. (YouTube to the rescue). Once I did that, it’s research to figure out how hard this is to replace and where I can get the part.

    I logically move through the steps of how can I practically get things done.

    From here, I saw someone talk about this on YT and show me this isn’t hard. I learned how to shift into Drive with a pair of vice grips, got it up to the house, and I found the part online. I ordered it, send the YT link to the kids, and tasked them with fixing the cable.

    They did, after some problem solving from me.

  • Monday Monitor Tips: Customizing Data Retention

    One of the biggest challenges with monitoring data is managing the volume over time. Lots of bespoke/home-grown solutions don’t do this well, and some commercial products have a gross approach that might not meet your needs.

    Customers constantly ask me about this, so here’s a quick tip on how you can manage data retention in Redgate Monitor.

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

    Checking the Configuration

    As with most things in Redgate Monitor, this is a config item. In your Redgate Monitor solution (or on the public demo site), you can find the configuration gear icon in the upper right.

    2025-05_0114

    Click this and you get to the settings page. Scroll down to the Preferences area and there is a Data retention settings link. Click that.

    2025-05_0116

    You will get to the Data retention settings page (public site), which has a few sections at the top. You will be setting this per Base Monitor, using the drop down at the top.

    Scroll below these to the data retention section, which you see at the bottom:

    2025-05_0117

    In this section, you see quite a few different sections. I’m showing the trend data below.

    2025-05_0118

    There are sections for

    • trend data- long term data for understanding how performance and baselines work
    • performance troubleshooting data – query, waits, plan, etc. data

    Each of these sections is described, along with where the data is displayed. You can see that in the image above.

    To the right of these, are the retention settings. I’ve got an image of the first few items. You can see the time for which to retain data and then the current size of that data.

    2025-05_0119

    You can set a fairly granular level of retention for data here, broken out by the various data elements we capture.

    The choices for retention are shown below, including indefinitely (be careful of this one).

    2025-05_0120

    We have this documented, along with what we think are good defaults on this page. For example, we keep top query data for only one week, since this is a lot of data. However, if you want more time, then set it to something that works for you.

    Summary

    Data management is always a challenge, both in production databases and in our monitoring systems. Redgate Monitor gives you lots of choices, and those can vary by Base Monitor, so if you have a BM in the cloud doing some stuff and one on premise doing other things, you can set separate retention settings. That can be handy, especially when the cost of storing things can vary dramatically.

    Watch this over time and adjust settings as needed to keep your system performing optimally.

    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.

  • The Book of Redgate: Ingeniously Simple

    Redgate has been known for many useful tools that are easy to use. We’ve tried to do that in all our point tools. We talk about simplicity all the time and when we release something that isn’t simple, lots of people question why.

    Perhaps not enough or with enough pushback, but we do talk about simplicity.

    One of the pages in the book was devoted to merely expressing ingeniously simple. It’s written in a number of languages.

    2025-05_0105

    The goal of ingenious simplicity is to build things that people can use without resorting to complex manuals and example code. SQL Compare is a great example of this. Enter a few database connections and click Compare and you get an easy report. There’s a big Deploy button on top to help you sync your databases.

    I think we’ve done a good job of building some simple tools over the years. Perhaps now we’re in a more complex environment, but we are trying to keep things simple and provide clues to help users understand how the tools work.

    I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

  • A Basic Update Trigger: #SQLNewBlogger

    I had someone ask me about using triggers to detect changes in their tables. As I explained a few things, I thought this would make a nice series, so I’ve written a few posts on triggers that can be useful. This one looks at detecting a change to a column in a trigger.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    The Setup

    I’ve got a Customer table that I want to use, which doesn’t have any triggers on it. Here is the schema.

    CREATE TABLE [dbo].[Customer](
         [CustomerID] [int] NOT NULL,
         [CustomerName] [varchar](200) NOT NULL,
         [AddressKey] [int] NULL,
         [CustomerStatus] [int] NULL,
         [CustomerContact] [varchar](100) NULL,
         [ContactEmail] [varchar](100) NULL,
      CONSTRAINT [CustomerPK] PRIMARY KEY CLUSTERED 
    (
         [CustomerID] 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

    I also have a logging table where I can store messages from a trigger, which is better than direct output.

    Let’s create a trigger. I’ll use an UPDATE trigger here to check if a column is changed and then insert a logging message.

    Note: I’m not trying to be efficient here, just create an action based on what changed. THIS IS NOT PRODUCTION QUALITY CODE.

    Here is a basic trigger using the UPDATE() function to check if a column changed. I am inserting into the logger table when I detect a change, but in a real application, I’d likely have some business logic here instead of the insert.

    CREATE TRIGGER Customer_tru ON dbo.Customer FOR UPDATE
    AS
    BEGIN
         IF UPDATE(CustomerName)
             INSERT dbo.logger (logdate, logmsg) VALUES (DEFAULT, 'dbo.Customer.CustomerName changed')
         IF UPDATE(AddressKey)
             INSERT dbo.logger (logdate, logmsg) VALUES (DEFAULT, 'dbo.Customer.AddressKey changed')
         IF UPDATE(CustomerStatus)
             INSERT dbo.logger (logdate, logmsg) VALUES (DEFAULT, 'dbo.Customer.CustomerStatus changed')
         IF UPDATE(CustomerContact)
             INSERT dbo.logger (logdate, logmsg) VALUES (DEFAULT, 'dbo.Customer.CustomerContact changed')
         IF UPDATE(ContactEmail)
             INSERT dbo.logger (logdate, logmsg) VALUES (DEFAULT, 'dbo.Customer.ContactEmail changed')
    END

    Now, I’ll check the time, then run an update, and select from the logger table. This gives me a nice easy way to see what changes were logged. First, let’s update one field.

    We can see that the change was logged. I could add more info, but this is just a check of what happened.

    2025-05_0227

    Let’s check two changes. We can see that both are detected below.

    2025-05_0228

    Now I’ll update all the fields in a row. There are five other than the PK and I can see all changes logged.

    2025-05_0229

    Note that I’m just detecting an update to this field and marking it as changed. If the value were set to the same value, which some apps do, this is still noted as an update by this trigger. To determine if this value was actually changed, I’d need to compare the inserted and deleted rows.

    That’s a quick look at detecting which fields have changed. In the next post, we’ll look at more information in the trigger.

    SQL New Blogger

    Getting started blogging can be hard. I’m sure many of you have used a trigger. Why not write about setting up a trigger, perhaps with some logic like this. Have you used updated()? Tell us how and why.

    This is a great way to showcase how you approach a problem. This is a basic post here, but I’ve shown above I could do something business related instead of the insert to the logger table.

    This was a 15-20 minute post.