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.
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.
Open the Mini DBA page that matches the symptom:
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.
Before asking the question, decide what to include:
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.
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.
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.
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.
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:
| 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 |