Mini DBA MSP mode lets one Mini DBA Console connect to multiple Mini DBA Engine instances so managed service providers, distributed DBA teams, and multi-site organizations can monitor separate database estates from one browser interface. Use this page as the main guide for MSP database monitoring, cross-engine alert triage, engine selection, customer separation, and operational ownership.
What MSP Mode Is
MSP mode starts when the console has more than one Mini DBA Engine connection. Each engine collects metrics from the database servers it can reach. The console brings those engines together so users can review estate health, alerts, reports, server groups, licensing, and engine connection state without opening a separate console for every customer, site, region, or network.
This is useful when database servers are separated by firewalls, customer networks, cloud accounts, operational teams, or data residency boundaries. Instead of forcing every monitored server to be reachable from one monitoring host, you can deploy an engine near each estate and connect them to one console.
Common MSP Deployment Patterns
- One engine per customer for managed service providers.
- One engine per site, region, or data center.
- One engine per cloud account or subscription boundary.
- One engine for production and another for non-production.
- One engine per network zone when firewall rules prevent central collection.
- Separate engines for ownership, resilience, or maintenance-window boundaries.
Each engine remains responsible for its own database connections, sampling, alert generation, license state, service logs, and local network access. The console is the shared operational view.
MSP Setup Workflow
- Install and start each Mini DBA Engine close to the database servers it will monitor.
- Open Settings in the console.
- Add each engine connection with a clear display name, service endpoint, credentials, and auto-connect preference.
- Test and connect each engine.
- Open Servers and add monitored database servers to the engine that owns them.
- Use Server Groups to group servers by customer, environment, region, platform, or owner.
- Configure Alert Recipients, Recipient Groups, and notification channels.
- Use Copy, Export, And Import Alert Configuration when servers or customer engines should share a standard alert policy.
- Open Enterprise View and Alerts to confirm cross-engine visibility.
Engine Ownership
Every monitored database server belongs to one engine. In an MSP environment, this ownership matters because it controls where metrics are collected, where alert history is stored, which service log contains collection errors, and which license count is used.
Choose the engine that has the correct network path, database credentials, host OS access, license capacity, and operational owner. Avoid adding a customer server to a central engine if the customer's local engine is the one that can reach the database reliably.
Viewing Alerts Across All Engines
Use the global Alerts page when you need a cross-engine alert triage view.
The Current tab on the global Alerts page is the fastest way to answer "what is alerting right now across the estate?" It lists current active alerts from all monitored servers known to the console, including servers from multiple connected engines. Use the priority, server, and search filters to narrow the list.
This all-engine current alert view is especially useful for:
- Morning operational checks.
- MSP command-center review.
- Major incident triage.
- Finding which customer, engine, or platform needs attention first.
- Spotting repeated alerts across several environments.
Viewing Alerts For The Current Selected Engine
In MSP mode, the console also has a current selected engine context. The side navigation tree is filtered to the selected engine, so the server list shows the customer, site, or engine estate you are currently working on.
Use this selected-engine workflow when you want to focus on one engine:
- Select the engine you want to work with in the console engine selector or Settings connection list.
- Use the navigation tree to view only servers that belong to that selected engine.
- Open a server and select its Alerts page for current, uncleared, history, configure, and maintenance-window tabs for that server.
- Use the global Alerts page Uncleared and History tabs for alert history from the current selected engine.
- Switch to another engine and refresh when you need to review that engine's alert history.
The distinction is important: global Alerts Current is designed for all-engine live triage, while selected-engine navigation and server-level Alerts pages are designed for focused investigation. Uncleared and History views are loaded through the current selected engine service.
Server-Specific Alert Pages
Each monitored server also has its own Alerts page. These pages are the best place to investigate one server because they include current alerts, uncleared alerts, alert history, alert configuration, and maintenance windows where supported.
Use server-specific Alerts pages when:
- One database server is affected.
- You need to configure or review alert thresholds for a server.
- You need maintenance windows for one server.
- You want alert history for a single SQL Server, Azure SQL resource, PostgreSQL server, MySQL/MariaDB server, or Oracle server.
See SQL Server Alerts, Azure SQL Database Alerts, PostgreSQL Alerts, MySQL And MariaDB Alerts, and Oracle Alerts.
Standard Alert Configuration Across Engines
MSP teams often need a consistent alert baseline across customers, environments, or support tiers. Mini DBA supports this from each server's Alerts page with Copy Config. You can copy alert configuration from another same-type server, copy the current server configuration to one or more same-type targets, or copy between connected engine instances when both engines are available in the console.
Use direct cross-engine copy when both Mini DBA Engine instances are connected and you want to apply a known policy immediately. Use export and import when an engine is offline, air-gapped, or managed through a separate deployment process. The export/import workflow uses the engine trigger database, normally trig.db, from the engine app data folder. For Linux or container engines this is commonly /var/lib/minidba-engine/trig.db; for Windows services it is commonly C:\ProgramData\MiniDBA Engine\trig.db; for Azure App Service it is commonly %HOME%\site\data\minidba-engine\trig.db.
Before copying a policy between customers, review notification groups, escalation routes, custom alert SQL, maintenance windows, and any customer-specific thresholds. Copying alert configuration overwrites the target server's alert thresholds and notification settings, so treat it as a controlled MSP change.
Enterprise View In MSP Mode
Enterprise View is the main cross-engine dashboard. Use it before drilling into servers when you need a quick estate picture. It helps identify unhealthy servers, alert counts, platform mix, engine health, and the first place to investigate.
For MSP teams, Enterprise View is usually the first screen for daily checks. It helps the team decide whether a problem is isolated to one customer or visible across several engines. From there, open the affected server, platform page, or alert record.
Licensing In MSP Mode
Each Mini DBA Engine has its own license. Activating, deactivating, or reviewing a license affects only the selected connected engine instance. The console does not apply one license to every engine.
Use Settings to review engine rows and the engine details modal. Check license name, expiry, SQL connection usage, and license status before adding more monitored servers. Use Licensing for activation and deactivation guidance.
Security And Roles
MSP deployments should separate console access, engine access, and database monitoring credentials.
Console administrator access controls settings, engine connections, license actions, integrations, and security settings. Engine credentials control whether the console can connect to an engine. Database monitoring credentials control what each engine can read from monitored databases.
Use least privilege for database monitoring users and avoid sharing customer credentials between engines. Use clear naming and documentation so support teams know which engine, customer, and owner are responsible for each monitored server.
Naming And Grouping Best Practices
Good names make MSP mode far easier to operate. Use engine display names that identify the customer, site, region, or environment. Use server groups to group monitored servers by customer, platform, production state, support owner, or business application.
In the Servers tree, use the Groups button at the top of the tree to switch from a flat list to grouped navigation. When grouped view is active, select Edit beside the Groups button to open Server Groups Settings and update group membership.
Recommended naming examples:
CustomerA-Production-EngineCustomerA-DR-EngineEMEA-SQL-EngineAzure-Prod-EngineInternal-NonProd-Engine
Avoid ambiguous names such as Engine1 or Server2 unless they are only temporary test connections.
MSP Troubleshooting
If an engine is missing from cross-engine views, open Settings and confirm it is connected. If servers are missing from the navigation tree, confirm which engine is selected because the tree is filtered to the selected engine in MSP mode.
If alerts are missing, check whether you are using the all-engine global Current view, selected-engine history, or a server-specific Alerts page. Then check Service Log for the engine that owns the monitored server.
If a database page is blank, verify the monitored server belongs to the expected engine and that the engine can still reach the database host. Right-click the server and open Connectivity Log for per-server connection errors, then check Service Log. Permission problems should be checked with the platform-specific connection guide.
MSP Mode FAQ
Does MSP mode require a separate console per customer?
No. One console can connect to multiple Mini DBA Engines. Each engine can represent a customer, site, region, or network boundary.
Can I view current alerts from all engines?
Yes. Open Alerts and use the Current tab. It shows active current alerts across all monitored servers known to the console.
How do I view only the current selected engine?
Select the engine you want to work with. The navigation tree filters to that selected engine. Use the server-specific Alerts pages for focused current alerts and use the global Alerts Uncleared and History tabs for the current selected engine's history.
Does each engine have its own license?
Yes. Each engine has its own license state, expiry, and monitored server count.
Where do I add engines?
Add engines from Settings. For the setup steps, see Multi-Engine Settings.
Where should I look when one customer's monitoring fails?
Start with Settings for that customer's engine connection, then check that engine's Service Log, server configuration, and platform-specific connection permissions.
Related Pages
- Multi-engine settings
- Settings
- Server Groups
- Connectivity Log
- Troubleshoot database connectivity
- Enterprise View
- Alerts
- Copy, export, and import alert configuration
- Servers
- Licensing