Voice of the DBA

Tag: Redgate Monitor

Monday Monitor Tips: Beyond SQL Server

Redgate Monitor works with more than SQL Server. Some big changes were announced recently, and I’ll cover the highlights here.

This post looks at Redgate Monitor and the additional monitoring available for Oracle, MySQL, and MongoDB.

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

Growing Up

The world has been slowly growing to embrace more database platforms. Not just as a whole, but I find more and more Redgate clients have lots of different database platforms. Our 2025 State of Database Landscape report shows that while there is a little consolidation from many companies having more than 4 platforms in 2024, there are still plenty that have 2 or 3.

As a result, we’ve been working hard to bring additional capabilities to Redgate Monitor beyond SQL Server. In 2023 we announced PostgreSQL support. Just recently we also added Oracle, MySQL, and MongoDB support.

We can see this in the online monitor.red-gate.com demo site. If we scroll down to the staging group, we see both MongoDB and MySQL being monitored.

Below these, we see Oracle 19 and 23 being monitored as well.

If you click into any of these cards, you’ll see there is a limited amount of information now, but we have teams growing and adding the metrics on a weekly basis. Right now, Oracle shows high level metrics and queries.

MySQL is similar

as is MongoDB

The supported platforms are in the docs for Oracle, MySQL, MongoDB, PostgreSQL, and SQL Server.

Summary

Redgate Monitor is growing up. I remember when it was just a small alerting system and now it’s a world class monitoring platform that is growing beyond SQL Server. If you have needs on other platforms, check it out and let us know what’s important to you.

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.

May 19, 2025
Monday Monitor Tips: Finding the Hostname for Queries

I was chatting with a customer recently and they wanted to know which host was sending in queries that were causing problems in real time. This post looks at where you can find the hostname for running queries, which is in two places.

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

The Server Overview

There are two places where you can see the host name. From the server overview, you can go to the current activity, or the new Query Executions tab in preview.

Current Activity

In the server overview, there is a lot of data, but most people scroll down to see the list of queries, such as this list from the ssc-db-n3 instance.

There is the database and lots of data, but no hostname. The reason is that these are aggregates. Each of these queries has run many times, possibly from different hosts. This is a historical view.

The better way to look for details on certain problem queries now is to look for current activity. I’ve zoomed in and highlighted this item below.

If I click that, I get an sp_who, or sp_whoisActive view of the server, and I can see the logins listed here. That’s helpful.

Still no hostname, but if I pick a query from a login, and see the details, I see this view.

In the lower left corner, I get the hostname. I’ve zoomed in below.

We could add that in the main box, but we’re trying to surface the most important info, and for most of our customers, that isn’t the hostname. However, we have added it in the detail.

If you’re like it in the main box, or would like to choose which fields are there (maybe host and not program?), send us a note to your rep or to sales@red-gate.com.

Query Executions

For some of our servers, we have a new Query Executions tab that uses Extended Events to get some data. The Workload02 system has this enabled. You can see the tab at the top, and then the view of this below.

If I zoom in to the lower right, you can see the hostname as part of the details for query executions, along with other data. As you are examining the details of those queries which have run for over 5 seconds, you can get the metadata about the host, application, and more.

Summary

Hostnames are available, you just need to learn where to look. Hence this post. Hopefully this gives you a quick tip on how to find them.

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.

April 21, 2025
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.

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.

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.

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.

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.

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.

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

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.

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.

March 24, 2025
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.

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

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

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.

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.
February 24, 2025