Troubleshoot Database Connectivity

Start Here

Manual Home Installation Getting Started Licensing Servers Connect Database Servers Troubleshoot Connectivity Host OS Login Enable WMI Multi-Engine Settings

Console

Console Overview Enterprise View AI Assistant Execution Plans Alerts Custom Alerts Reports Settings Service Log Connectivity Log Web Log About

PostgreSQL

Overview Connection and Permissions Activity Databases Queries Waits Memory I/O Indexes Deadlocks Server Log Settings Permissions Health Checks Alerts Performance Tuning

MySQL/MariaDB

Overview Connection and Permissions Activity Databases Queries Memory I/O InnoDB Permissions Deadlocks Health Checks Alerts Performance Tuning

Oracle

Overview Connection and Permissions Activity Databases Queries Waits Memory Health Checks Alerts Performance Tuning

Settings And Integrations

Security SQL Options Email Server Alert Recipients Recipient Groups Server Groups Cloud Providers Web Proxy Slack Microsoft Teams PagerDuty Jira Performance Logging AI Provider MCP Server

Use this guide when Mini DBA cannot connect to an engine, cannot add a monitored database server, or connects but does not collect enough data. Connectivity troubleshooting is usually fastest when you separate console-to-engine problems from engine-to-database problems.

Screenshot pending: Mini DBA connectivity troubleshooting workflow

Start With The Right Scope

Mini DBA has two important connection paths:

Console to Mini DBA Engine: the browser console calls the selected engine over the configured engine service endpoint.
Mini DBA Engine to database server: the engine connects to SQL Server, Azure SQL, PostgreSQL, MySQL, MariaDB, or Oracle using the monitored server configuration.

If the Settings page cannot connect to an engine, start with Settings, Multi-Engine Settings, and Web Log. If the engine is connected but a monitored database server fails or shows partial data, start with Connectivity Log, Service Log, and the platform-specific connection guide.

Console To Engine Checks

Open Settings.
Confirm the engine row shows connected.
Verify the display name, endpoint, credentials, and auto-connect setting.
Test the engine connection from the engine row action menu.
Check whether port 8734 is reachable from the console host to the engine host.
Review Web Log for console-side errors.
Review Service Log if the request reaches the engine but the engine rejects or fails the action.

In MSP mode, also confirm the selected engine context. A database server that belongs to one customer engine will not be available from another engine that cannot reach that network.

Engine To Database Checks

Confirm the Mini DBA Engine host can resolve the database host name.
Confirm firewalls, security groups, VPN rules, and listener ports allow traffic from the engine host.
Confirm the database login or identity can authenticate from the engine host.
Confirm the target database, service name, instance name, or Azure SQL server name is correct.
Open the server's Connectivity Log from the tree context menu.
Open Service Log for broader sampling or background task errors.
Open the server permissions modal and refresh permission checks.
Apply missing grants from the platform connection guide.

Common Failure Patterns

Symptom	Likely Area	Next Step
Engine row will not connect	Console to engine service	Check endpoint, port `8734`, credentials, and Web Log.
Add Server fails immediately	Engine to database network or login	Check host, port, firewall, username, password, and Connectivity Log.
Server connects but pages are empty	Database permissions	Refresh the permissions modal and apply missing grants.
Activity works but queries, logs, or plans are missing	Optional permissions or extensions	Review the platform-specific connection guide.
Host CPU or disk metrics are missing	Host OS login, WMI, performance counters, or cloud provider metrics	Review Host OS Login, Enable WMI For SQL Server Monitoring, or Cloud Provider Settings.
Failures happen only during incidents	Network, load, timeout, or resource pressure	Compare Connectivity Log, Service Log, and historical performance pages.

Platform-Specific Pointers

SQL Server: check Windows or SQL authentication, SERVER\INSTANCE naming, SQL Browser or static ports, TLS settings, and VIEW SERVER STATE.
Azure SQL: check Azure SQL firewall rules, authentication mode, tenant or identity mapping, server-level permission in master, and database-level grants in each database.
PostgreSQL: check pg_hba.conf, SSL requirements, port 5432, monitoring roles, and required extensions such as pg_stat_statements.
MySQL and MariaDB: check user host patterns such as 'minidba_monitor'@'%', port 3306, PROCESS, SHOW DATABASES, and sys.* execution grants.
Oracle: check listener host, port 1521, service name, CREATE SESSION, SELECT ANY DICTIONARY, and common user setup for multitenant databases.

When To Capture Logs

Capture logs after reproducing the issue. Note the exact time, selected engine, monitored server, database platform, visible error message, and whether the problem was engine connection, Add Server, sampling, permissions, host metrics, or a specific page.

Do not share secrets, passwords, connection strings, API keys, customer identifiers, or sensitive query text. Use a short time window around the failure rather than exporting unrelated historical logs.