SQL Server and Azure SQL
revisit waits, queries, resource pressure, files, alerts and deadlocks.
Most database incidents are reported after the workload spike, blocking chain or resource pressure has gone. Mini DBA Engine collects continuously so the Console can return to the affected time and reconstruct what the server, database and queries were doing.
Historical monitoring is most useful when signals remain connected. A CPU graph alone cannot explain an incident, but the same time window combined with queries, waits, alerts, deadlocks, files and sessions can establish a defensible cause and show whether the behaviour is recurring or getting worse.
- Return to an incident window after the live symptom has disappeared.
- Compare metrics, queries, waits, alerts and deadlocks over the same period.
- Identify recurring workload patterns and emerging capacity pressure.
- Create evidence-led incident reviews, handovers and tuning priorities.
One investigation pattern across different database platforms
Mini DBA keeps the workflow consistent while exposing the platform-specific evidence needed for a reliable diagnosis.
PostgreSQL
compare query activity, locks, vacuum, WAL, connections and host pressure over time.
MySQL and MariaDB
analyse statement load, InnoDB health, connections, replication and I/O trends.
Oracle
investigate sessions, SQL, waits, memory, I/O, tablespace capacity and alert history.
Monitor every database platform from one Console
A practical investigation workflow
Start from evidence, narrow the scope and verify the result instead of applying a generic tuning checklist.
- 1
Select the affected server and narrow history to the reported incident window.
- 2
Find the first signal that changed rather than assuming the largest graph is the cause.
- 3
Correlate workload, waits, alerts and resource metrics, then drill into the relevant query or event.
- 4
Compare with a normal period and retain the evidence for remediation, capacity planning or client reporting.
Use AI beside the evidence
The Mini DBA AI Assistant can start with a focused question and optionally include the selected metrics, alerts, sessions, query, plan or event. Use it to explain evidence and propose checks; a DBA remains responsible for verification and production changes.
Ask across the estate with MCP
The Database MCP Server lets an approved AI client move from an estate-wide question to affected servers and historical detail, including multi-client workflows used by support and MSP teams.
Continue the investigation
Performance history documentation
Learn how stored monitoring history is organised.
Reports
Review estate and monitoring reports.
AI performance tuning
Use selected history as optional AI investigation context.
Database MCP
Ask approved AI clients questions across estate history.
Investigate the database problem, not just the platform
Use a problem-led workflow across SQL Server, PostgreSQL, MySQL, MariaDB, Oracle and Azure SQL.
Blocking and lock contention
Find the lead blocker and understand every waiting session.
Investigate blocking →Deadlock analysis
Preserve participants, statements and resources after the event.
Analyse deadlocks →Query performance
Prioritise expensive workload and inspect execution plans.
Analyse queries →Performance history
Reconstruct incidents after the live symptoms have gone.
See what is slowing your databases down
Install Mini DBA on Windows, a suitable Linux VM or a supported container platform, connect an Engine and start collecting the evidence behind performance incidents.