Voice of the DBA

Author: way0utwest

Monday Monitor Tips: Using the PowerShell API
Redgate Monitor has grown tremendously from its early days and I find many customers using this to monitor lots of servers, like thousands. In those cases, some of tasks you might do to manage your Redgate Monitor server can be cumbersome in the GUI.

This post shows you how to get started with PowerShell to administer your Redgate Monitor Instance.

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

The Purpose of the PowerShell API

Redgate Monitor (RGM) has lots of configuration options that you can set. In any size estate, this can be overwhelming when you need to change settings for some servers, but not others. For example, suspending some monitoring for servers being patched or upgraded. While this can be done easily in the web interface, for more than 1 or 2 servers, you might want a programmatic way to do this.

The PowerShell API is designed to help you change your configuration in a programmatic way rather than clicking through the GUI. If you look at the main documentation screen below, it says the same thing.

Getting the PowerShell Module

To get the various PoSh modules you need, you need to go to your configuration screen and click the download under the PoSh API section. You can see this below, and it’s also in the docs.

While this downloads, you also need an authorization token from your install. This is also on the configuration screen and described in these docs. The PowerShell API section has the Authorization Tokens section. Click that and in this screen you can genernate a new one. Save this, as you can’t see it after generation.

From here, test making a basic connection to your server with a script like this one below. One of our solutions specialists wrote it, and it imports the module, sets the URL and token, and then tries a connection. If that works, you are connected. You can run the Get-RedgateMonitorMonitoredObject as well. This gets a list of all objects being monitored.

Where to go from there is up to you. What types of things do you find yourself changing in Redgate Monitor? If there are a series of stops, then think about automating them. We have a set of example scripts that might give you some examples. There are things you might do from a list of servers like:
- add to a group (or move)
- suspect monitoring
- annotate them with an event
- set a tag
- copy settings from one server to another
With PowerShell, there are so many ways to program a script to do the thing you used to do manually. Give it a try with Redgate Monitor today.

https://youtu.be/eTlg1auKRUA

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.
January 20, 2025
Setting up a Local LLM
I wanted to experiment a bit with an LLM and training it, so I decided to try a few things. I looked at a few tutorials (see the references below) and then finally got this working. This post distills down what I got to work.

Getting Started

I like containers, and rather than install something on my machine, I decided to get docker images for ollama. I ran this to get started:
```
docker pull ollama/ollama
```
I ran the Docker container with this command:
```
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
```
From there, I pulled a few models into the container with these commands:
```
docker exec -it ollama ollama pull mistral
```
I then ran this to start the model and interact with it.
```
docker exec -it ollama ollama run mistral
```
Here are a first few things I typed in to test the model.

From here, I exited and then ran this to start the model in detached mode.
```
docker exec -d ollama ollama run mistral
```
From there, more experiments, but that’s in another article.

References

Here are some places and tutorials I looked at:
January 20, 2025
The Types of Changes

I would guess that most of you reading this piece are database professionals in some sense. Either you work on databases as a developer of some sort (app and/or database) or manage them as a DBA or sysadmin. In working with databases, I’m sure that you need to alter object structures. Maybe you perform a lot of changes, or maybe you just alter the schema occasionally, In either case, you need to make decisions on which changes to make.

I would guess that the most common changes are altering stored procs/views/functions. Often these are to handle new or updated business rules. In those cases, how do you ensure you haven’t added regressions? I would hope you had a set of test scripts to verify that your results are correct. If I were very optimistic, I’d hope that you had a set of automated tests, such as those you could write with tsqlt or the Microsoft Unit Test Framework.

I’m sure many of you add new columns to tables. What are these types of changes? Capturing new data? Splitting existing columns or de-normalizing data? In these cases, are you re-examining the data model to ensure the changes make sense?

Maybe even more importantly, if you are capturing new data, do you consider vertical partitions for the table? This can be a good way to separate out data in columns that isn’t queried as often. Despite most recommendations, lots of developers will still SELECT * from tables, which can flood the buffer cache with data that isn’t often needed by an application. Vertical partitions can reduce the impact of these types of queries.

For those of you that add new data, do you consider using different data types for your new data, or do you have a standard string/numeric/date type that you use? SQL Server (and other platforms) often have a variety of different data types that can save space, while still accommodating the requirements for a change. As an example, many people use datetime as a standard type when they just need a date. In this case, we could save 5 bytes per row by choosing a more appropriate type.

If you add status values or flags, have you considered bit storage for your values? Whether you use the bit datatype or bits in an int, you can dramatically save space in each row. Newer versions of SQL Server include T-SQL functions to help you work with bits, though I would hope most developers can handle simple AND/OR logic against an integer to test if a particular bit is set.

Most software under active development has a need to continually alter and modify the database to meet new requirements. While lots of us have experience in making these changes, and do so often, once we make a change it often becomes enshrined in our production system for years. I would hope that we feel confident in refactoring our code as needed, but the reality of what I often see is that people are loathe to change the database for fear of breaking our software. Even when the refactoring actually improves the performance of the application.

I’m curious what types of changes you often make, and how you go about deciding on the specifics of the change. Let us know about your approach in the discussion. I’m especially interested in how you might handle the various options for changes. Do you assume defaults or are you explicit in how you structure your ALTER code?

You might have a novel way of examining requests and implementing changes that can help others in learning to ensure they make better changes in their own system.

Steve Jones

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

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

January 17, 2025
Advice I Like: Apologies

How to apologize: quickly, specifically, sincerely. Don’t ruin an apology with an excuse – from Excellent Advice for Living

This is great advice. I remember myself often saying “I’m sorry, but …”, which takes away from the I’m sorry. In fact, I wasn’t really sorry.

I’ve learned to just apologize. No excuses, no qualifications, just apologize for what you (or often, I), did. Leave it at that.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

January 17, 2025