nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
- SolarWinds Academy
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
- Goal Oriented AI
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Best Practices for Server Upgrades

James123456

Is there a how-to document or best practices doc that include steps to prepare SQL Sentry for changes made to the server such as an OS upgrade, adding memory, CPU, or disk space?

I'm looking for a way for SQL Sentry to be able to see server changes and keep the history.

Find more posts tagged with

improving_upgrades

SQL Sentry

Product: SQL Sentry

Accepted answers

PJC

That clarification helps. Stopping monitoring before the change and restarting it afterward will not, by itself, preserve the history if the OS upgrade causes SQL Sentry to identify the host as a new server. CPU, memory, disk, or SQL Server edition changes on the same host should generally be handled without deleting and re-adding the monitored target, but an OS replacement needs to be treated as a planned migration. I’d capture a baseline beforehand, document the change in your normal change record, and verify the target identity after the upgrade before making any registration changes.

All comments

PJC

SQL Sentry can help with the performance side of this by retaining historical data and showing baseline changes after hardware or configuration updates. For the actual CPU, memory, disk, and upgrade details, I’d still keep a change record in your normal CMDB or change-management process, then use SQL Sentry to validate the performance impact before and after the change.

This overview may help: SQL Sentry Overview

James123456

Hi PJC,

Thank you for your quick response. I don't think I'm asking correctly. I'm trying to keep the SQL Sentry history when making server configuration changes.

I'm looking for a process document for administrators to follow when upgrading or changing server configurations. For example a document that says to always stop watching the server before making changes, then reboot the client, then reboot the SQL Sentry database server, then start watching the server, etc., etc.

Last year, we upgraded the Windows OS on a server and SQL Sentry stopped monitoring the server. We submitted a ticket to SolarWinds where we learned that a new OS is viewed as a completely new server, so we had to remove the server and add the server again…which meant we lost all previous history.

Our goal is to have SQL Sentry compare the performance impact before and after the change. I understand there might not be a document that lists if SQL Sentry will be able to continue monitoring a server if you add CPU or change from Standard Edition to Enterprise Edition, but it won't be able to continue monitoring a server if you upgrade the OS. I just wanted to ask if anyone has seen anything that might help SQL Sentry monitor continuously if and when there are server changes.

PJC

James123456

I appreciate all your advice PJC. In addition to what you are saying, Solarwinds provided this document to fix our FCI issue with SQL Sentry. We ran the stored procedure in this document and it started reporting correctly. I hope this helps others in this situation.

Exec WSFC.AlignFailoverClusterInstance 0

https://documentation.solarwinds.com/en/success_center/sqlsentry/content/monitoring/enhanced-fci.htm

Pkelley33

Hey @James123456 .

So if we are just talking about general system/hardware changes, these should get picket up automatically with an hourly scan. This can also be done manually by right clicking a target in the Navigator pane > "Scan for Configuration Changes"

Now, if the Server Name and/or IP changes, this is typically more where we run into the issue you mentioned. Some have had some luck with updating server name/domain/IP related columns in the "Device" and "EventSourceConnection" tables, but this may not always work, especially depending on other layers of factors like clustering, aliases, etc.