SQL Server Performance Prescriptive Recommendations: Go Beyond Alerting

Ask most SQL Diagnostic Manager customers what the tool does for them, and the answer is almost always some version of the same thing: it watches our servers and tells us when something’s wrong. That’s true, and it’s valuable. It is also only about half the story.

SQL DM does not just tell you when something is wrong. It tells you what to do about it. Underneath the dashboards and the alert feed sits a recommendations engine that surfaces specific, prioritized guidance based on what it actually observes in your environment: configuration issues, query patterns, index opportunities, and more. Most customers never open it. The IDERA tutorial Five Key Features of SQL Diagnostic Manager for SQL Server covers it directly, and it is worth watching before you assume you already know everything SQL DM can do for your environment.

Prescriptive recommendations in SQL Diagnostic Manager are specific, prioritized guidance the platform generates based on what it observes in a monitored SQL Server environment, including configuration issues, query patterns, index opportunities, and more. It goes beyond alerting to tell a DBA what to actually do about a problem, not just that one exists.

Five Key Features of SQL Diagnostic Manager for SQL Server

Ask Yourself: Are You Watching, or Are You Acting?

There is a simple question worth putting to any team that has run SQL DM for more than a few months: beyond monitoring and alerting, are you using it to get actual guidance on what to fix, or is it being used primarily as a watch-and-alert tool? For the large majority of customers, the honest answer is the latter. Dashboards get checked. Alerts get triaged. The recommendations panel sits there, generating guidance that nobody is reading.

That is a genuinely surprising amount of unused value sitting inside a tool teams already own and already pay for. It is not a locked feature behind a higher tier. It is not something that requires a professional services engagement to turn on. It is already running, already analyzing the environment, and already waiting to be opened.

What the Recommendations Engine Actually Does

SQL DM’s recommendations engine continuously analyzes the same performance data the platform is already collecting, including configuration settings, query execution patterns, index usage, wait statistics, and more. It turns that analysis into specific, prioritized guidance rather than a generic health score.

In practical terms, it can surface things like:

• Configuration settings that deviate from best practice for a given workload or SQL Server version.
• Query patterns that are consistently expensive or inefficient, with enough context to know where to start tuning.
• Missing or underused indexes that would meaningfully improve query performance.
• Prioritized guidance, so a DBA knows which recommendation to act on first rather than facing an undifferentiated list.
• Environment-specific context, because the same recommendation engine is analyzing your servers, not a generic industry benchmark.

Why Teams That Use It Call It “Having an Expert Looking Over Your Shoulder”

That phrase comes up often enough among customers who have actually spent time in the recommendations panel that it is worth taking seriously as a description of the experience.

The comparison holds up because of what the recommendations engine is actually doing: it already knows the nuances of a specific environment, including its configuration, its workload, and its query patterns. It uses that context to prioritize what matters most, the same way an experienced SQL Server consultant would after spending real time in an environment.

The difference is that this expertise is available continuously, at no incremental cost, to every team running SQL DM. It is not something that requires bringing in outside help or waiting for a scheduled health check. It sits quietly in the background, doing the kind of analysis a senior DBA would do if they had unlimited time to review every server, every day.

A Reasonable Cadence for Working Through Recommendations

Teams that get real value out of this feature tend to treat it as a habit rather than a one-time discovery. A simple, sustainable cadence:

1. Open the recommendations panel for each monitored instance and review what is currently surfaced.
2. Sort or prioritize by the guidance SQL DM already provides. Start with what it flags as most impactful, not the longest or most technical item on the list.
3. Address what is reasonable to fix immediately, and document what requires a maintenance window or stakeholder sign-off.
4. Build a monthly review into the team’s existing process, rather than treating this as a one-time cleanup exercise.
5. Revisit after any significant workload or configuration change, since new patterns can surface new recommendations.

Some customers build exactly this into a monthly review and find it keeps the environment consistently well-tuned, instead of drifting between periodic, larger tuning efforts.

What’s Different for Teams Not Yet Using It

If a team is mostly watching dashboards and responding to alerts today, there is a whole layer of proactive value sitting unused inside a tool they already have installed. The recommendations engine is worth spending real time in. No SA is required to get started, since it is already analyzing the environment and already generating guidance.

The lowest-friction way to start is not a full audit of every recommendation across every server. It is picking one instance, opening the recommendations panel, and seeing what is already there.

Recommendations vs. Alerts: What Each One Is Actually For

Alerts tell you something happened. Recommendations tell you what to do next.

Where This Fits in a Crowded Monitoring Market

SolarWinds markets AI Query Assist and ML Anomaly Detection. Redgate and Quest lean heavily on dashboards and alerting depth. Where SQL DM differentiates is not a bigger AI feature list. It is transparency.

Prescriptive recommendations are explainable and specific to the environment generating them. A DBA can inspect, understand, and choose whether or how to apply the guidance, rather than relying on a black-box model making decisions silently in the background.

For teams that want AI-driven insight without giving up visibility into why a recommendation was made, that is the practical difference: an expert looking over your shoulder, not a black box making decisions for you.

What to Track Once Your Team Starts Using Recommendations

• Number of recommendations reviewed and acted on per monitoring cycle.
• Time-to-resolution for recurring performance issues, before and after adopting a regular review cadence.
• Configuration and index changes made directly as a result of a recommendation.
• Team confidence in root-cause analysis, especially for less experienced DBAs relying on prioritized guidance.

Frequently Asked Questions

Do I need a separate license or add-on to use prescriptive recommendations?

No. The recommendations engine is part of the existing SQL Diagnostic Manager license and is already analyzing every monitored environment. There is no additional tier or professional services engagement required to start using it.

How does SQL DM decide what to recommend?

The recommendations engine continuously analyzes the performance data SQL DM already collects, including configuration settings, query patterns, index usage, and wait statistics for a specific environment. It then surfaces prioritized, specific guidance rather than a generic industry benchmark.

How is this different from an alert?

An alert tells you something is happening right now, based on a threshold. A recommendation tells you what configuration, query, or index issue is likely causing a recurring problem and what to consider doing about it. This closes the gap between symptom and root cause.

How often should a team review recommendations?

Some customers build a monthly review into their process and find it keeps the environment consistently well-tuned. Ad hoc review works too, but a regular cadence tends to catch drift before it becomes a bigger problem.

Can a DBA see why a recommendation was made?

Yes. Recommendations are explainable and grounded in the specific environment they come from, so a DBA can inspect and understand the reasoning rather than accepting an unexplained automated decision.

If your team has been treating SQL Diagnostic Manager purely as a watch-and-alert tool, the fastest way to find out what you have been missing is to open the recommendations panel on a single instance this week and see what is already sitting there, waiting to be read.

Start a free 14-day trial of SQL Diagnostic Manager

Ask your account team for a recommendations walkthrough