Skip to content

[FEATURE] Allow custom database file locations during install #768

@jakemorgangit

Description

@jakemorgangit

Which component(s) does this affect?

  • Full Dashboard
  • Lite
  • SQL collection scripts
  • Installer
  • Documentation

Problem Statement

Currently the install process creates the monitoring database using the instance default data and log paths.

That’s fine for most dev/test deployments, but in most production environments those defaults aren’t where database files should live.

Common setups separate:

  • Data and log files onto different volumes
  • Dedicated locations for DBA-managed databases

As a result, the PerformanceMonitor database can end up in a non-standard or suboptimal location unless it’s manually moved after install.

Proposed Solution

Add an option to specify database file locations at install time, for example:

  • Data file path
  • Log file path

If provided, use these paths when executing CREATE DATABASE with explicit FILENAME values.

If not provided, retain the current behaviour and fall back to:

SERVERPROPERTY('InstanceDefaultDataPath'),
SERVERPROPERTY('InstanceDefaultLogPath')

Use Case

Typical production setup where:

  • Data files live on something like D:\SQLData
  • Log files live on something like L:\SQLLog

When installing Performance Monitor, the database should be created directly on the specified volumes rather than relying on instance defaults. In some environments, instance default locations may reside on lower-performance storage for cost reasons, making it even more important to control file placement explicitly.

This avoids having to:

  • Move files post-install
  • Take the database offline
  • Update file locations (and any file permissions) manually

Alternatives Considered

Changing instance default paths

  • Not ideal as this affects all databases on the instance

Installing then manually moving files

  • Requires downtime and extra steps
  • Easy to forget or misconfigure

Additional Context

  • Not version-specific, applicable across all supported SQL Server versions
  • No schema changes required
  • Would likely be used in most production deployments

Happy to put a PR together for this if it’s something you’d be open to 👍

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions