High Availability Options for Database Performance Analyzer (DPA)

3/12/2026 3:16 PM

3/12/2026 3:16 PM

This article explains what is and is not currently supported for high availability (HA) with SolarWinds Database Performance Analyzer (DPA), and outlines practical ways to make your DPA deployment more resilient within those limits.

The key idea:

• DPA supports HA at the database (repository) layer

• DPA does not provide native clustering or automatic failover for the DPA application server itself

Database Performance Analyzer

1. DPA Architecture – Why HA is database‑centric

DPA’s core architecture is intentionally simple:

• One DPA server (Java/Tomcat web application)

• One DPA repository database where all performance and configuration data is stored

Because all critical data lives in the repository, the product is designed so that:

• You can use your database platform’s HA/HADR features to protect the repository

• You use your infrastructure/OS/VM tools to make the single DPA server as resilient as you need

---

2. What DPA does support for High Availability

2.1 HA for the DPA repository database

DPA supports hosting the repository on a highly available database platform, for example:

• SQL Server Always On Availability Groups (AG) with a listener

• SQL Server failover cluster instances

• Equivalent HA/HADR solutions on other supported database engines

DPA connects to the repository using a normal JDBC connection string. If your HA database is exposed via a listener or cluster endpoint, you simply point DPA at that endpoint. As long as that endpoint keeps resolving and accepting connections, DPA will follow database failovers without needing to be reconfigured.

2.2 Monitoring high‑availability databases

DPA can monitor databases that are already running in HA configurations. Examples include:

• SQL Server Availability Groups

• Other high‑availability or clustered database setups

In these cases, the database environment uses HA, and DPA:

• Tracks the health and status of those databases

• Raises alerts or shows status changes as designed

---

3. What DPA does not support today

It’s important to be very clear about current limitations:

3.1 No native HA/cluster for the DPA application server

• DPA is designed as a single application server per repository.

• There is currently no built‑in clustering or active–active support for multiple DPA servers.

• There is no built‑in automatic failover or load balancer integration that moves users between DPA servers.

You can absolutely run the DPA server on a highly available virtual or physical platform, but the HA logic lives in your infrastructure and in the database layer—not inside DPA itself.

3.2 No “floating/standby” licensing for multiple DPA servers

• Licenses are tied to a specific DPA server instance.

• Running multiple active DPA servers against the same repository is not supported.

• A smoother “standby/floating” licensing experience for active–passive DPA deployments is a requested feature, not something that is currently available.

4. How to build a supported HA design for DPA

Within those constraints, here is the supported and recommended approach.

4.1 Make the DPA repository database highly available

Step 1 – Choose an HA‑capable repository platform

1. Use a supported database engine for the DPA repository (commonly SQL Server or Oracle).

2. Deploy that database in your preferred HA configuration:

   • SQL Server: Always On AG with a listener, or a failover cluster instance

   • Other platforms: their native HA/HADR equivalent

Step 2 – Move or create the repository on the HA platform

If you already have a DPA repository:

1. Prepare the HA environment

   • Create the DPA repository database on the HA‑enabled platform, or

   • Add the existing DPA repository database into your HA group/cluster.

2. Migrate the data

   • Use your database platform’s normal backup/restore or migration tools.

   • DPA’s repository is fully contained in a single schema/database, so you can move it as a unit.

3. Update the DPA connection string to use the HA endpoint

   • On the DPA server, open the repo.properties file under the DPA installation directory (inside the ignite_config / configuration folder).

   • Update the connection details so DPA connects to the HA listener or cluster endpoint, not a specific node:

     • For SQL Server Always On, use the AG listener name.

     • For other HA solutions, use the appropriate logical service or endpoint.

   • Save the file and restart the DPA service so it picks up the new settings.

4. Test database failover

   • Perform a controlled failover of the repository database inside your HA platform.

   • Confirm that:

     • The listener/endpoint remains reachable from the DPA server.

     • DPA reconnects and continues operating without additional configuration changes.

If you are deploying a new DPA repository:

1. Create the repository database directly on your HA‑enabled platform.

2. When configuring DPA, set the connection in repo.properties to the listener/service name from the start.

---

4.2 Make the DPA application tier resilient (within current limits)

Because DPA does not have native app‑level clustering, the supported options are based on your infrastructure.

Option 1 – One DPA server, protected by your platform

• Install DPA on a reliable virtual or physical server.

• Use your existing OS/virtualization HA features (e.g., hypervisor clustering, automatic VM restart) to handle host failures.

• Put a backup plan in place for the DPA server:

  • OS image or VM snapshots

  • DPA configuration files

  • SSL certificates and any customizations

All critical performance and configuration data lives in the repository. The DPA server itself can be rebuilt if needed, as long as it can reconnect to the existing repository database.

Option 2 – Disaster Recovery using a manually managed standby DPA server

If you need a DR option for the DPA server itself, you can use a manual failover pattern that stays within supported boundaries:

1. Install a second DPA server that is configured to connect to the same repository.

2. Keep this standby server:

   • Stopped or disconnected during normal operation.

   • Never running at the same time as the primary DPA server against that repository.

If the primary DPA server is lost:

1. Confirm the primary server will not be brought back online.

2. Start the DPA service on the standby server.

3. Redirect users to the standby server URL.

4. Coordinate with SolarWinds Support or your account team if any licensing changes are required, since licenses are tied to specific servers.

This approach:

• Gives you a way to recover the DPA application in another location

• Avoids unsupported active–active configurations

• Keeps you aligned with the “one DPA server per repository” design

It is not an automatic or clustered failover; it is a documented manual DR process.

5. Summary

• DPA supports HA for the repository database using your database platform’s HA/HADR features and a listener/cluster endpoint.

• DPA does not have native HA/clustering for the application server; it is a single‑server application per repository.

• For resiliency:

  • Make the repository database highly available.

  • Protect the DPA server with your standard OS/VM HA tools.

  • If needed, use a manual DR standby DPA server (kept offline until needed) rather than trying to run multiple active DPA servers against the same repository.

This design gives you a supported, predictable way to improve availability and recovery time for DPA without relying on unsupported clustering or failover mechanisms in the application layer itself.