Voice of the DBA

Tag: Redgate

Monday Monitor Tips: Native Replication Monitoring

Redgate Monitor has been able to monitor replication for a long term, but it required some work from customers. Now we’ve added native monitoring.

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

New Native Monitoring

The monitoring capabilities in Redgate Monitor were originally fairly limited to a few counters from PerfMon. A few people had written custom metrics on sqlmonitormetrics.com that clients could use, but we’ve had customers asking for more native integrations.

We’ve done it. With version 14.2, we have added an estate view of your replication environment. In the Estate menu, there is a new entry for Replication Monitoring.

If I click this, I get a list of the jobs running replication across various servers. You can see this below, with each instance and the job denoted by a REPL- at the start. These are the defaults that Microsoft sets up and should be left alone.

You can see below that the agent server name is listed, and I can click it to get to that server overview in Redgate Monitor. I also have the category and job name to the side. Beyond that we have the last completed run if it’s successful. If it’s running, the Job Ended is blank. To the right we have the publisher, subscriber, and distributor names.

I can resort the columns, such as below when I am looking by category.

I can also sort by publisher:

Or subscriber (or any other column).

Clicking the column a second time reverses the sort order.

Alerting

There are two new replication specific alerts available for the job failures and maintenance job failures. These work the same as any other alert in Redgate Monitor and can be configured for specific servers, groups, levels, etc., with notifications going out to all the notification targets.

Here are the alerts in the alert configuration.

These jobs run across the various replication categories: distribution, merge, snapshot, log reader, and queue reader.

If I look at the details, I can see the job failure works across multiple categories and is set to a high level alert. I can adjust this as I can with any other Redgate Monitor alerts, and exclude jobs if I wish with a regular expression.

The replication capabilities are documented here: https://documentation.red-gate.com/monitor14/sql-server-replication-314869637.html

Summary

Replication isn’t something most people use, but for those that do implement it, monitoring is critical. Redgate Monitor has added some native capabilities to let you get a glimpse of your entire replication estate at once and get notified if there are issues.

Replication can be amazing, but I find it brittle. When it works, it’s amazing, but when it breaks, it’s broken. Getting a jump on issues is important for many organizations and Redgate Monitor can help you do that.

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.

December 15, 2025
Flyway Tips: Automation Assistance in Flyway Desktop

I was chatting with the product managers at Flyway and one asked me whether I’d seen the new tab for Automation in Flyway Desktop. I hadn’t and decided to take a quick look at how this works and what’s useful. This post looks at the new feature.

Tl;Dr this is a good way to start learning how to move to a more DevOps, automated way of deploying changes.

I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Working with Flyway Desktop

For a lot of customers, it’s not too hard to setup a project and start to capture code in a Git repo. However, adding in automation gets challenging for many, especially as the docs are hard to understand if you don’t already have some knowledge. I find that CI/CD is a bit of a chicken and egg challenge as we try to learn to get better, but knowing what to learn and do requires knowledge.

Which we don’t have.

In any case, I’ve taken an existing Flyway project where I am capturing some code. You can see the project below, with objects on the right. The database and the repo have the same object code and are in sync.

Let’s add a few new objects to this database in SSMS. You can see below I’m adding a new table and altering a proc. I’m also refactoring slightly to not keep the old style join convention in my proc as I add a new join.

Once I do this, in Flyway Desktop (FWD), I see my changes. I’ll save these to the repo and then generate a migration script. I won’t show that as it’s not important.

Once I’ve done this, I know I want to deploy code. If I go to Migrations, I can see I have these two scripts ready to go to QA, and I can deploy them with FWD manually. However, I don’t want to do that.

I want some automation. How does FWD make that easy? Let’s see.

The Automation Tab

There’s a new tab on the left, which is the Automation tab. I’ve expanded the left menu out and you can see it, but it’s a lightning bolt, which I might never have noticed (hence this post).

If I click this, I get a little explanation at the top, a few links, and then some CLI based code. This last part is the important part of what I need to move to CI/CD.

If you look at the code closely, you’ll see some placeholders in angle brackets for the environments I need. The code looks like this:

Above this, there are two drop downs where I can select my build and target environments. Build is the CI portion, and it’s a good idea to have a place to build code separate from QA. This lets me validate things, and more importantly, run some code analysis checks, summarize changes, and detect drift.

I’ve expanded the Build drop down below and you can see I have my environments listed, and I can also manage them from here. There is also an Environments tab on the left menu just above Automate Deployments that looks like a database icon.

Once I select an environment, the code changes to reflect this. That makes things easier to automate as I can take these commands and drop them into a task in my CI/CD tool.Note in the image below that I’ve selected NWInt and the code shows target2. The code needs the ID (or PK) of the environment, but the display name I entered is shown in the drop down. Trust me, these match.

I’ll also select a target and then open up a CLI to run the first item on line 5. I did have to auth, but this runs successfully. No doc checks, no experimenting, the command ran.

I’ve never saved any snapshots and so the drift doesn’t work right away, but I’ll get the dryrun script. When I run this, I get a summary from the CLI.

Then I can see the report (see above output for the path at the end. When this opens, on the Dry Run tab, I see my scripts.

Note, I did use the drop downs in FWD to select the environments I need for this.

Very cool.

Summary

One of the challenges with using Flyway is that there are a lot of settings, options, and more that one must learn to take advantage of the solution. Our docs continue to improve, but even for someone that has been using Flyway for a few years, I have to constantly check out things work. Plus, the teams are adding features on a regular basis, so it can get confusing to learn the new things.

This automation tab is really helpful to shortcut some of the things I need for the various environments in my project. I’m going to start using some of this in a new project, and so should you.

Flyway can do much more, and for smoother automation, check out Flyway Enterprise.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

December 8, 2025
The Book of Redgate: What Our Staff Says

This image is from 2010, and it goes along with my last post of what our Customers Say about us. However, this is what our employees said about the company.

At this point we would have been around a 200 person company, mostly in the UK. It’s a great list of words, and if I were looking for a new employer, this type of work cloud might get me interested in applying.

Redgate has often felt like an extended family, where we care about each other, we’re bonded, and we’re working together to get through life. We disagree and bicker at times, but we love each other.

We’re now closer to a 600 person company, and I don’t know that all of us, or even most of us, feel the same ways, but I’d like to think most people still think this is a great place to work.

I do.

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.

December 5, 2025
Reverse Engineering a Physical Model Diagram

I recently wrote about a logical diagram with Redgate Data Modeler. That was interesting, but creating all the objects is a pain. I decided to try creating a physical diagram from an existing database. This post looks at the experience.

This is part of a series of posts on Redgate Data Modeler.

Getting Started

As with the logical model, I right click and choose New document.

Then I get a list of options. I’ll choose the middle one, Physical Model. This is what I mostly need to work with an existing system. Since I don’t often move models from one platform to the other, a physical diagram can work well for me.

Once I click next, I get a list of platforms, and I need to enter a name. I’ve done that. Notice that when I select SQL Server, I can alter the drop down for different versions of SQL Server.

Below this, I see a source box, and a file picker.

I need a file.

I’ll go to SSMS and right click my database. I’ll find the Generate Scripts task, as shown below.

I go through the wizard and mostly pick defaults.

I do script to one file, not separate ones. I choose all objects.

Back to Data Modeler with the file. I select this and upload it and see…an error.

When I open the script, I see lots of non-database stuff.

I’ll delete this stuff and also a bit at the bottom. I rename this to Westwind.sql, which is what I am importing. Then I was able to import the file and when I clicked “Start modeling”, I ended up with this:

Redgate Data Modeler (RDM) has detected quite a few relationships. You can see them in the diagram for the explicit ones defined. If I click one, such as the Order to Order Details item, I can see on the right that this is for OrderID in both tables..

One thing that threw me slightly was two Employees tables. I was wondering what was going on here, but when I clicked the lower one and looked through properties, I can see that this is for a different schema. I wish this were more visible, but it did get detected.

Cleaning up the Design

One of the things I like is that I can set areas in the model. This lets me organize things and even convey information to developers and others that work with the database.

At the top left, I have a series of icons. The last one on the right is the New Area icon. I’ll click this.

I can now draw an “area” somewhere. Notice the right when I do this. I have properties for this area.

I’ll add a name and change the color, which gives me way to easily see this area in my diagram. I’ll also drag in the Auditing.Employees table, as this is what I want people to know.

I can select this and move it (look at the video) and then I see this as a part of my diagram, but clearly separate from other parts. Developers can learn the light red is the auditing schema, which is separate from the rest of the diagram.

I can add other areas, not just for schemas, but for separating out parts of my database. Often I have a series of entities that I care about, or want to cluster together, and having areas with colors lets me separate these out.

I might run out of colors in a large database, but I could use lots of pale blues or grays to separate out areas, each of which has a name. That can be helpful to reduce the complexity of the model.

Adding a New Table

I can also add a new table if I want. One of the icons at the top is for new tables.

When I click in the model, a new table appears. The right opens up the properties with a default name (table14). I can change this and add the columns I need.

Once I’ve finished, I can add a relationship. There is an icon for this.

I’ll click this and then click and drag from Products to Discount. This gives me a new column in Discount by default, called Products_ProductID. Not a bad name, but in general I want a cleaner name. I’ll edit the relationship to use ProductID in both tables and delete the other column from the model.

Modeling with an image is a good way to start to visualize how things are setup and where you might be normalizing, or denormalizing data. I also want to know just how many things are in here and what is related to what.

Moving Forward

There are more things that can be done with tools like that to help ensure our databases are well designed and perform well. I’ve submitted feedback to the team and asked for some enhancements.

One of the things I might want to do from here is update my dev db from the model. I’ll show that in a future post.

For now, I like the idea of getting a model started from my SQL script, though clearly I need a clean script. I’ll do more testing with other scripts for both forward and reverse engineering.

Give Redgate Data Modeler a try and see if it helps you and your team get a handle on your database.

December 1, 2025