SQL Server and Azure SQL
connect requests, lock waits, open transactions and execution plans.
Blocking turns a small transaction problem into slow applications, timeouts and queues of waiting work. Mini DBA shows the sessions holding locks, the work waiting behind them and the wider performance context needed to choose a safe response.
A blocker is not automatically the session to terminate. It may be completing useful work, waiting on another resource or sitting inside an application transaction. Continuous monitoring and history let you identify the lead blocker, understand the statements involved and confirm whether the pattern is isolated or recurring.
- Identify the lead blocker and every session waiting behind it.
- Inspect SQL text, transaction age, waits and resource use before intervening.
- Retain blocking evidence after the live sessions have completed.
- Alert on sustained blocking while filtering short, harmless contention.
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
expose blocked and blocking backends, lock modes and idle-in-transaction risk.
MySQL and MariaDB
investigate InnoDB lock waits, long transactions and connection pressure.
Oracle
relate blocked sessions to blockers, wait events, SQL and transaction state.
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
Start with the application symptom, active alert or server showing an unusual session queue.
- 2
Open activity and lock detail to locate the head blocker and inspect all participating statements.
- 3
Compare waits, resource graphs and recent history to distinguish lock contention from a wider bottleneck.
- 4
Correct the transaction or query pattern, then use history and alerts to confirm the problem does not return.
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
SQL Server activity
Sessions, requests and blocking detail in the Console.
PostgreSQL activity
Inspect PostgreSQL sessions, queries and transaction state.
MySQL and MariaDB activity
Investigate current connections and executing statements.
Oracle activity
Review Oracle sessions, SQL and waits.
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.
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.
Explore history →
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.