Tag: Redgate

  • The Book of Redgate: What’s Great about Redgate?

    “I’m sick of hearing about Red Gate.”

    The first article in the book has this title, which might seem strange, but the short piece then talks about how many Redgaters, as we call ourselves, love working for the company and tell our friends how great a place this is to work.

    The question it asks is why is Redgate great? It’s not the benefits, the gatherings, the fun things, the inside jokes. It’s not even the open, collaborative way or working, the no BS no politics attitude. It’s not anything that’s easy to put into words.

    It’s really the culture, which is hard to describe. It’s like a family, which is similar to what I felt at J. D. Edwards as well. We have good and bad, we have disagreement and arguments, but overall we’re all in this together.

    We’ve grown since then, and it’s a different place, but it’s still a great place to work and one that I hope I stay with until I retire.

    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.

  • The London Redgate Summit

    In a week I’m heading to London for the Redgate Summit. I enjoyed these last year and had some very interesting conversations with customers, prospects, and a few Redgate fans.

    This year the event is on Mar 11 at the Tottenham Hotspur Stadium, which should be fun given that I’ve been re-watching Ted Lasso (I still need to make a pilgrimage to Richmond…).

    The schedule has a variety of tracks for leadership and tech people. There are even some breakfast sessions if you want to learn more about Oracle or PostgreSQL. I’ve got the keynote session and a panel for leadership on my agenda.

    Check out the video from last year, and register to come this year. I’ll see you in London next week.

  • Monday Monitor Tips: VLF Alerts

    A recent change made to Redgate Monitor to add a new alert for VLF count. This post looks at the change.

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

    Tracking Virtual Log Files

    Virtual Log Files (VLF) are sections inside of your physical log file (.ldf). These have no fixed size or number per file, but there can be many. The architecture of the log is explained in this doc and it varies according to a number of factors.

    That doc also explains there are issues with too many VLFs inside of a log file. There are plenty of other posts about this (Brent Ozar, Kimberly Trip) and it is somethin you want to keep track of.

    Redgate Monitor changes and grows every week with new releases and one of the resent releases (14.0.41) included a new alert for VLFs.

    2025-02_0318

    To configure this, select the gear icon in the upper right of Redgate Monitor.

    2025-02_0319

    On the configuration page, select the Alert settings. This will bring you to the details for your alerts.

    2025-02_0320

    There are a number of items on the Alert Settings page, but scroll down to the bottom of the SQL Server Alerts section. The Virtual log file count is the last alert.

    2025-02_0321

    The default setting is to raise multiple alerts here. The settings are:

    • low: 100
    • medium: 300
    • high: 1000

    These may or may not be appropriate  for your system, and for me, I don’t know I’ve ever had time to worry about this and I might disable a low level alert and only have two, but you can decide what’s important to you.

    The important thing is that if you worry about VLFs in your environment, you can get alerted and track this over time.

    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.

  • Adding Manual Relationships Between Tables in the TDM Subsetter

    I wrote about getting the Redgate Test Data Manager set up in 10 minutes before, and a follow up post on using your own backup. One of the things I didn’t show from my own database was that it had no FKs, so the subsetting didn’t quite work as I wanted.

    A previous post showed how add starting tables for the subsetter to look at, however that didn’t get me a good data set for testing. This post continues looking at the subsetter by adding manual relationships to our configuration.

    This is part of a series of posts on TDM. Check out the tag for other posts.

    Declaring a Relationship in the Options File

    In my previous post, I’d picked a starting table and had reduced the dbo.players table from 16564 to 1800. However, I only had player information. If I query my subset database, I see there is a player, but I have no batting statistics for this player.

    2025-01_0196

    This is because my table has no declared FKs in it. If I check the dbo.batting table, I can see only a PK.

    2025-01_0197

    Let’s fix this.

    Declaring Manual FK Relationships

    In the options file documentation, there is a section that notes manual relationships can be declared with a key called “manualRelationships”. If I copy/paste the example section into my options file, I’ll see this:

    2025-01_0198

    I don’t have a SourceTest table, so let me edit things. I’ll set a relationship between dbo.players.playerID and dbo.batting.playerID. This gives me the following in my options file.

    2025-01_0199

    Before I run my subsetter, here are the row counts by table.

    2025-01_0200

    I’ll re-run this subset command, which includes my option file at the end.

    rgsubset run --database-engine=sqlserver --source-connection-string="server=localhost;database=BB_FullRestore;Trusted_Connection=yes;TrustServerCertificate=yes" --target-connection-string="server=localhost;database=BB_Subset;Trusted_Connection=yes;TrustServerCertificate=yes" --target-database-write-mode Overwrite --options-file E:\Documents\git\TDM-Demos\rgsubset-options-bb.json

    When I do that, I know see these row counts. Note I now have batting rows.

    2025-01_0201

    My player query won’t work, so I still need to declare another relationship with the dbo.teams table. That is shown below:

    2025-01_0202

    I can re-run the same command above, and then I see this set of rowcounts (original on left, subset on right).

    2025-01_0203

    There is teams data, and if I re-run my queries from the top, I can see stats now.

    2025-01_0204

    Now I have a dataset that I can perform development work with in terms of players, teams, and batting.

    I can also add more relationships as needed, for example, I’ll add this section to include pitching, batting post, and fielding. Here’s my complete options file:

    {
      "jsonSchemaVersion": 1,
      "startingTables": [
        { 
          "table":
          {
            "schema": "dbo",
            "name": "players"
          },
          "filterClause": "birthState = 'CA'"
        }
      ],
      "manualRelationships": [
        {
          "sourceTable": 
            { 
              "schema": "dbo", 
              "name": "players"
            },
          "sourceColumns": [ "playerID" ],
          "targetTable": 
            { 
              "schema": "dbo", 
              "name": "batting" 
            },
          "targetColumns": [ "playerID" ]
         },
         {
            "sourceTable": 
              { 
                "schema": "dbo",
     
                "name": "batting"
              },
            "sourceColumns": [ "teamID", "yearID", "lgID" ],
            "targetTable": 
              { 
                "schema": "dbo", 
                "name": "teams" 
              },
            "targetColumns": [ "teamID", "yearID", "lgID" ]
           },
           {
              "sourceTable": 
                { 
                  "schema": "dbo", 
                  "name": "players"
                },
              "sourceColumns": [ "playerID" ],
              "targetTable": 
                { 
                  "schema": "dbo", 
                  "name": "battingpost" 
                },
              "targetColumns": [ "playerID"]
             },
             {
                "sourceTable": 
                  { 
                    "schema": "dbo", 
                    "name": "players"
                  },
                "sourceColumns": [ "playerID" ],
                "targetTable": 
                  { 
                    "schema": "dbo", 
                    "name": "pitching" 
                  },
                "targetColumns": [ "playerID"]
               },
               {
                  "sourceTable": 
                    { 
                      "schema": "dbo", 
                      "name": "players"
                    },
                  "sourceColumns": [ "playerID" ],
                  "targetTable": 
                    { 
                      "schema": "dbo",
     
                      "name": "fielding"
                    },
                  "targetColumns": [ "playerID"]
                 }
      ]
    }
    

    After re-running the subsetter, I have these row counts. Note there are rows in all the tables defined in the options file.

    2025-01_0205

    I can keep adding in more tables as needed to ensure the subsetter can walk down the data relationships I need in my database to produce a useable dev/test dataset that’s smaller than production.

    TDM can help your devs build better software and with the subsetter, this can create lots of agility to ensure the data you need to accurately build this software is available.

    Give TDM a try today from the repo and a trial, or contact one of our reps and get moving with help from our sales engineers.

    Video Walkthrough

    Check out a video of my demoing this below: