Performance Tuning With AI In Mini DBA


Mini DBA AI Assistant can help turn monitoring evidence into a practical performance tuning plan. The most effective workflow is to start on the page closest to the symptom, include the right context switches, ask for evidence first, then use follow-up questions to narrow the action.

Mini DBA AI performance tuning screenshot placeholder

When To Use AI For Performance Tuning

Use AI assistance when you have enough Mini DBA evidence to describe a performance problem but want help prioritizing the next step. Good examples include high CPU, high waits, blocking, plan regressions, memory pressure, I/O latency, deadlocks, slow queries, or a sudden change after deployment.

Avoid using AI as the first and only source of truth. The assistant is strongest when the context includes current Mini DBA metrics, sessions, alerts, query data, waits, and execution plan evidence.

Step 1: Start From The Right Page

Open the Mini DBA page that matches the symptom:

  • CPU pressure: use CPU, Activity, Queries, or Query Store.
  • Blocking: use Activity, Locks, Waits, or Deadlocks.
  • Memory pressure: use Memory, Queries, or Indexes.
  • I/O pressure: use Files, Drives, I/O, or waits.
  • Query regression: use Query Store, Cached SQL, Activity, or execution plan detail.
  • Estate-wide triage: use Enterprise View or the global Alerts page, then drill into one server.

Starting on the right page matters because the AI context includes the page name and the live model snapshot for the server or view you selected.

Step 2: Choose Context Options

Before asking the question, decide what to include:

  • Enable Metrics for CPU, memory, waits, I/O, service tier, and host evidence.
  • Enable Sessions for active requests, blockers, blocked sessions, current sessions, and query-level details.
  • Enable Alerts when the active alert list is part of the incident or you want the assistant to explain alert severity and thresholds.

For a broad tuning question, start with Metrics and Sessions. Add Alerts when the issue is alert-driven. If the prompt becomes too broad, turn off Sessions and ask a metrics-only question first.

Step 3: Use Get Insights

Select Get Insights when you want Mini DBA to generate a standard performance analysis prompt. The generated prompt asks the assistant to review potential bottlenecks, resource patterns, optimization recommendations, and concerning trends for the current live state or selected historical time range.

This is a good first prompt:

Analyze the current live state for this server and rank the top three performance risks. Explain the evidence from Mini DBA first, then list the next checks I should run.

The response should give you a short investigation order rather than a random list of database tuning ideas.

Step 4: Ask Evidence-Led Follow Ups

After the first answer, ask specific follow-up questions. The panel keeps conversation history for the current server or page context, so the assistant can refer to the previous answer.

Useful follow-up prompts include:

Which metric in the Mini DBA snapshot most strongly supports that conclusion?
What should I check before changing indexes or server settings?
Separate likely query tuning actions from infrastructure capacity actions.
Write a handover note for the on-call DBA with evidence, risk, and next action.

Step 5: Use Execution Plan AI For Query Tuning

For query-specific tuning, open the query or plan detail and use the AI option from the execution plan context. Plan context can include SQL text, plan XML, PostgreSQL plan text or XML, MySQL plan tree or JSON, or Oracle plan operators depending on the platform and page. See Execution Plan Analysis for the cross-platform workflow and links to the database-specific plan controls.

Ask focused plan questions:

Find the first operator I should investigate and explain why.
Does this plan suggest missing indexes, stale statistics, parameter sensitivity, or excessive row estimates?
Give me a safe tuning order that avoids making broad server-level changes first.

Always validate plan recommendations against workload frequency, writes, storage impact, and deployment process. An index that helps one statement can hurt write-heavy workloads.

Step 6: Turn The Answer Into A Change Plan

Ask the assistant to produce a change plan only after you have confirmed the evidence. A good final prompt is:

Create a change plan with low-risk checks first, then query/index changes, then capacity changes. Include rollback and validation steps.

The best output should include:

  • What evidence justifies the change.
  • Which team owns the action.
  • How to test safely.
  • What success metric to watch after the change.
  • How to roll back if the change makes performance worse.

Common Performance Tuning Use Cases

Use Case Best Starting Page Context To Include
High CPU CPU, Activity, Queries, Query Store Metrics and Sessions
Blocking Activity, Locks, Waits Sessions and Alerts
I/O latency Files, Drives, I/O, Waits Metrics
Memory pressure Memory, Queries Metrics and Sessions
Query regression Query Store, Cached SQL, execution plan detail Sessions and plan context
Alert-driven incident Alerts, then related performance page Alerts plus Metrics

Related Pages