1. 1
   Log in to DPSMF

   Navigate to your DPSMF URL and log in with your admin credentials. First-time users will be prompted to set a password on initial login.
2. 2
   Open Instance Manager

   Go to Settings → Instances → Add Instance. Enter the SQL Server hostname or IP address, port (default 1433), and credentials. SQL Auth and Windows Auth are both supported.
3. 3
   Test the Connection

   Click Test Connection. DPSMF will verify connectivity and permissions. A green check confirms the instance is reachable and the monitoring account has the required permissions.
4. 4
   Baseline Learning Period (7 Days)

   DPSMF observes silently for the first 7 days, building statistical baselines for every query hash, wait type, and resource metric. No alerts fire during this period — this is expected behaviour.
5. 5
   Alerts Go Live on Day 8

   From day 8, any deviation beyond 3σ from the learned baseline triggers an alert. The longer DPSMF runs, the sharper the baselines become. False positive rates typically drop below 6% after 30 days.

1. 1
   Open the Trial Form

   Click Start Free Trial on the Pricing page or navigate directly to dpsmf.ai/trial.html. No credit card is required.
2. 2
   Fill in Your Details

   Enter your full name, work email address, organisation name, and choose a tier from the dropdown. Create a password of at least 8 characters.
3. 3
   Submit and Save Your License Key

   On success the page displays your DPSMF-XXXXXX-XXXXXX-TRIAL license key. Copy it immediately — it is also emailed to you, but the email may take a few minutes to arrive. You will need the key on first login.

1. 1
   Navigate to Login

   Go to dpsmf.ai/dpsmf-login.html or click Log In from any DPSMF page. Enter the email and password you registered with.
2. 2
   Activate Your License Key

   After login, if your account does not yet have an active license you will see the License Activation prompt. Paste your DPSMF-XXXXXX-XXXXXX-TRIAL key and click Activate. The key is validated server-side and tied to your account — it cannot be used again.
3. 3
   Land on the Dashboard

   After activation you are taken to the main dashboard at /app/. The dashboard is initially empty — no instances are connected yet. The trial countdown begins at this point.

1. 1
   Open Instance Manager

   From the dashboard, click Instances in the left sidebar, then click + Add Instance. Alternatively go to Settings → Instances → Add.
2. 2
   Enter Connection Details

   Fill in: Instance Name (display label), Server Host (hostname or IP), Port (default 1433), SQL Server Version (2016–2025 or Azure SQL). Select authentication: SQL Auth (username + password) or Windows Auth (service account via Kerberos).
3. 3
   Verify Connectivity

   Click Test Connection. DPSMF will attempt a lightweight DMV query (SELECT @@VERSION) to confirm network and credentials. Common failures: firewall blocking port 1433, incorrect hostname, login not mapped to a database. See Requirements for the full permission list.
4. 4
   Select Databases to Monitor

   After a successful test, DPSMF lists all databases on the instance. Choose which ones to include in per-DB monitoring. System databases (master, tempdb, msdb) are always included for wait-stat and config analysis.
5. 5
   Save and Begin Collection

   Click Save Instance. DPSMF begins polling immediately at 15-second intervals for wait stats, DMVs, and execution plans. The instance card on the dashboard shows a green Live badge within 30 seconds.

DPSMF does not generate recommendations immediately. The Intelligence Engine needs to observe a representative sample of workload patterns — typically one full business day — before the Knowledge Graph can distinguish normal from anomalous behaviour.

During the baseline period you can still use Sentinel in Query Mode — ask questions like "What are my top wait types right now?" or "Show me execution plans for queries over 5 seconds." These are answered directly from live DMV data without requiring a trained baseline.

After the baseline window closes, Anomaly Detection activates and the alert system comes fully online. Here is what to expect on Day 2:

1. 1
   Dashboard Alert Cards Appear

   The dashboard shows active alerts sorted by severity (Critical → Warning → Info). Each card shows the affected instance, the alert type, and a one-line Sentinel summary. Click any card to open Sentinel with the alert pre-loaded into context.
2. 2
   Open Sentinel for Root-Cause Analysis

   Sentinel displays its evidence chain: the triggering metric, correlated wait types, execution plans, and Knowledge Graph context nodes. Click Explain to get a plain-English explanation. Click Recommend to see prioritised remediation steps with confidence scores.
3. 3
   Configure Notification Channels

   Go to Settings → Notifications to add email, Microsoft Teams webhook, or SMS recipients. During a trial, alert emails are sent from alerts@dpsmf.ai. Add this address to your allowlist to avoid spam filtering.
4. 4
   Create Your First Runbook

   When Sentinel recommends a remediation step you want to formalise, click Save as Runbook. The runbook captures the evidence chain, the recommendation, and any notes you add — creating an institutional knowledge record that persists beyond your trial.

1. 1
   Open the Sentinel Dashboard

   Navigate to Sentinel in the top nav. The live SN1 stream shows current waits, batch rate, and memory state in real time. No configuration needed — this starts collecting on day 1.
2. 2
   Check the Baseline Ribbon

   The orange baseline ribbon on each metric tile shows what “normal” looks like for this instance. Current value turns red when it exceeds the 3σ threshold. Hover any tile for a 24-hour sparkline.
3. 3
   Drill Into Wait Stats

   Click Wait Analysis in the Sentinel panel to see the full wait category breakdown. The top 5 wait types for the current 10-minute window are ranked by total wait time, not count — this shows you what SQL Server is actually blocked on.
4. 4
   Correlate With Top Queries

   When CPU or I/O waits are elevated, click Top Queries to see which query hashes are responsible. Sort by avg CPU ms, avg reads, or execution count to find the culprit fast.
5. 5
   Set a Performance Alert Threshold

   Go to Alerts → Rules → Add Rule. Choose metric cpu_pct, batch_requests_sec, or page_life_expectancy. Set the operator and threshold, then choose a notification channel. The baseline-aware option fires only when the value deviates from learned normal — not just crosses a static number.

1. 1
   Open the Security Panel

   From the Sentinel dashboard, click the Security tab. The compliance score (0–100) for each connected instance is shown at the top. A score below 70 is flagged red.
2. 2
   Review Shadow Identities

   Click Shadow Identities. The list shows all logins and users with anomalous states. For each entry, the Risk column explains why it was flagged. Use the Export button to share the list with your security team.
3. 3
   Audit Permission Sprawl

   Click Permission Map. The tree view starts from sysadmin and expands downward through role chains to direct grants. Any path leading to CONTROL SERVER, ALTER ANY LOGIN, or db_owner on a sensitive database is highlighted in amber.
4. 4
   Check TDE Coverage

   The Encryption table lists every database with its TDE state, certificate thumbprint, and expiry date. Green = encrypted + cert valid. Amber = encrypted but cert expires within 90 days. Red = not encrypted.
5. 5
   Create a Security Alert Policy

   Go to Alerts → Policies → New Policy, choose template Security Baseline. This pre-configures alerts for: new sysadmin-role member, failed login rate > 10/min, TDE disabled on any new database, and off-hours interactive service-account login.
6. 6
   Export a Compliance Report

   Go to Reports → Security Audit. Choose the instance, date range, and output format (PDF or Excel). The report covers all 5 compliance dimensions and includes a remediation checklist.

1. 1
   Open Knowledge Graph

   Navigate to Intelligence → Knowledge Graph. The graph explorer loads with your instance’s most recently active nodes highlighted — these are the patterns most relevant to what your SQL Server is doing right now.
2. 2
   Search for a Symptom

   Use the search bar to enter a symptom in plain English, e.g. slow queries after index rebuild or blocking on tempdb. Results are ranked by semantic similarity to your query, not keyword match.
3. 3
   Read the Recommendation Chain

   Click any node to expand its detail panel. The Related Nodes tab shows the cause chain (upstream) and fix chain (downstream). Follow the chain from symptom → cause → diagnostic → remediation.
4. 4
   Use During an Incident

   When an alert fires, the alert detail page includes a Knowledge Graph Insight card. This card links directly to the 3 most relevant nodes for that specific alert — no manual searching needed during an incident.
5. 5
   Validate and Contribute

   Each node has a Validate button. Clicking it after following a recommendation that worked increases the node’s confidence score. Validated nodes are weighted higher in future recommendations for all users.

1. 1
   Open Index Health

   Go to Intelligence → Index & Query Health. The summary card shows: total missing index candidates, indexes with >30% fragmentation, and queries with plan regressions detected this week.
2. 2
   Review Missing Index Candidates

   The Missing Indexes tab lists candidates sorted by impact score (not raw column lists). Each entry shows the table, equality/inequality columns, included columns, and an estimated read improvement percentage. Click Generate Script to get a ready-to-review CREATE INDEX statement.
3. 3
   Prioritise Fragmentation Rebuilds

   The Fragmentation tab shows all indexes with >5% fragmentation, sorted by size × fragmentation impact. Indexes under 1,000 pages are marked REORGANIZE candidates; larger indexes are marked REBUILD. Use the maintenance window filter to schedule rebuilds outside peak hours.
4. 4
   Investigate a Slow Query

   Click Top Queries, then select any query hash. The detail pane shows: the query text, historical CPU/reads trend (30 days), current execution plan as a visual tree, and the AI reasoning chain explaining the bottleneck. The reasoning chain cites specific Knowledge Graph nodes so you can read the background.
5. 5
   Set a Plan Regression Alert

   In the query detail pane, click Watch This Query. If the execution plan changes and performance degrades by more than 20%, an alert fires with a side-by-side plan diff so you can see exactly what changed.

1. 1
   Open Configuration Intelligence

   Navigate to Intelligence → Configuration. The audit summary shows a score (0–100) and a count of settings flagged as Critical, Warning, or Advisory.
2. 2
   Review Critical Findings First

   Critical findings are configurations proven to cause data loss, corruption, or severe performance problems (e.g., max degree of parallelism = 0 on a 32-core NUMA system). These should be addressed before any other tuning.
3. 3
   Read the Recommendation Detail

   Click any finding to see: the current value, the recommended value, the reasoning (with SQL Server version context), the Knowledge Graph node it links to, and the risk of changing it. Some changes require a service restart — this is flagged prominently.
4. 4
   Generate and Review the Script

   Click Generate Fix Script on any finding. The script includes the current value as a comment so you can revert if needed. Always test configuration changes on a non-production instance first.
5. 5
   Enable Drift Alerting

   Go to Alerts → Rules → New Rule and select the Configuration Drift template. This fires within 60 seconds of any sp_configure change, any ALTER DATABASE to a monitored setting, or any tempdb file count change.

1. 1
   Set Backup SLA Windows

   Go to Settings → Instances → [Instance] → Backup SLA. Set the maximum allowed hours since last full backup and since last log backup (for databases in Full recovery model). DPSMF will alert if either threshold is breached.
2. 2
   Review Job Health Dashboard

   Navigate to Maintenance → Job Health. Every SQL Agent job is listed with its last outcome, average duration (30-day), and a trend sparkline. Red rows indicate a job that failed on its last run or is running significantly longer than normal.
3. 3
   Configure a Scheduled Report

   Go to Settings → Reports → New Report. Choose: report type (Daily Health, Weekly Executive, Monthly Trend), instances to include, output format (PDF or Excel), delivery channel (email address, Teams webhook, or ServiceNow assignment group), and delivery time. Click Save — the first report delivers on the next scheduled run.
4. 4
   Set a Maintenance Window

   In Settings → Instances → [Instance] → Maintenance Window, enter the start and end time (e.g., 01:00–05:00). Select days of week. During this window: no new alerts fire, anomaly scores are frozen, and performance metrics are excluded from baseline calculations.
5. 5
   Add a Job Failure Alert

   Go to Alerts → Rules → New Rule, select category SQL Agent. Choose: specific job name or “any job,” failure trigger (single failure or N consecutive), severity, and notification channel. Duration regression alerts are available under the same category.

Sentinel is the primary monitoring view in DPSMF. It shows a live feed of all connected instances, current health scores, active alerts, and real-time metric sparklines — all updated every 10 seconds.

The SN1 live feed delivers a sub-second stream of metric events, alert state changes, and anomaly detections via server-sent events. It powers the real-time indicators on Sentinel tiles.

Individual Sentinel features (anomaly overlay, AG health panel, capacity widgets) can be enabled or disabled per-user by an admin under Settings → Sentinel Features. This allows feature rollout to be controlled without a code deployment.

DPSMF collects instance-level metrics by default. Per-database monitoring extends this to track transaction log usage, index health, active query load, and alert thresholds individually per database — so a single busy reporting database does not mask the health of other databases on the same instance.

The AG Monitor tracks all Availability Groups on connected instances. It polls sys.dm_hadr_availability_group_states, sys.dm_hadr_database_replica_states, and sys.dm_hadr_availability_replica_states every 10 seconds.

1. 1
   Alert Fires

   A metric breaches its 3σ threshold (or a configured static threshold). The alert appears in the live feed with severity: Info, Warning, or Critical.
2. 2
   Acknowledge

   Click Acknowledge to indicate the alert has been seen. An unacknowledged alert will escalate to email after 60 minutes.
3. 3
   L2 Escalation

   If still unacknowledged after 120 minutes, the alert escalates to L2 with an urgent email. The alert manager shows an escalation badge.
4. 4
   Resolve

   Once the underlying condition clears, click Resolve and optionally add a resolution note. Resolved alerts are archived and contribute to the knowledge graph for future pattern matching.

Each alert opens a detail view showing the metric timeline, the anomaly score at the time of firing, correlated events within ±30 minutes, and AI-generated root cause analysis with a specific recommended action.

1. 1
   Go to Settings → Policies

   All active policies are listed here with their scope (instance, database, or global) and current status.
2. 2
   Choose Policy Type

   Select Baseline (fires when deviation exceeds Nσ), Threshold (fires when metric exceeds a fixed value), or Absence (fires if a metric stops being collected).
3. 3
   Set Scope

   Scope the policy to a specific instance, a specific database, or apply it globally across all monitored instances.
4. 4
   Configure Severity & Suppression

   Set the severity (Info / Warning / Critical) and optionally configure a suppression window (e.g., suppress between 01:00–05:00 during maintenance windows).

DPSMF enforces license-level policy limits. Monitor tier allows up to 10 active policies per instance. Intelligence and Enterprise tiers are unlimited. Policy checks are evaluated before every alert fires — a suppressed policy will not alert even if the condition is met.

A runbook is a structured set of steps that appears automatically when a specific alert type fires. Instead of DBA tribal knowledge living in someone's head, runbooks encode the correct response procedure and make it instantly available to any engineer on call.

1. 1
   Go to Settings → Runbooks → New Runbook

   Give the runbook a name and description. Choose which alert type(s) it attaches to (e.g., all blocking_count critical alerts).
2. 2
   Add Steps

   Each step has a title, detail text, and an optional verification query — a read-only T-SQL query that the engineer can run to confirm the condition before and after applying a fix.
3. 3
   Set Escalation Path

   If the runbook steps don’t resolve the issue, configure the escalation contact (name, email, phone) shown at the bottom of the runbook view.
4. 4
   Activate

   Toggle the runbook to Active. It will now appear automatically in the alert detail view whenever a matching alert fires.

DPSMF’s anomaly engine builds a rolling baseline for every tracked metric using a 7-day sliding window. It computes the mean and standard deviation for each metric at each time-of-day and day-of-week slot, then scores incoming values against the expected distribution.

When an anomaly fires, DPSMF searches the previous 30 minutes for other anomalies on the same instance. Correlated events are ranked by temporal proximity and knowledge graph relationship strength, then presented in the alert detail view as likely contributing causes.

The knowledge graph is DPSMF’s long-term memory. Every query hash, wait type, metric event, and alert is stored as a node. Observed relationships between them — temporal co-occurrence, causal linkage, query-to-wait attribution — are stored as edges. A taxonomy layer classifies nodes into categories (workload, resource, maintenance, replication, etc.).

Open Knowledge Graph → Explorer (/kg-explorer.html) to browse nodes and edges interactively. Search by query hash, wait type name, metric name, or alert ID. Click any node to see its connected edges and the evidence strength for each relationship.

DPSMF fits a linear trend model to each capacity metric (CPU, buffer pool, data file size, log file size, connection count) using the last 30 days of collected data. It extrapolates forward and identifies the projected date when each metric will breach its defined capacity threshold.

Instances are added through a slide-in panel directly on the dashboard — no separate page required. The panel is always accessible from the top navigation bar.

1. 1
   Open the Instance Panel

   Click the ＋ Instance button in the top-right of the navigation bar. A panel slides in from the right, listing all currently connected instances. The active instance is highlighted.
2. 2
   Click Add New Instance

   Scroll to the bottom of the panel list and click Add New Instance (shown as a dashed card). The panel switches to the 3-step wizard view.
3. 3
   Step 1 · Select Engine

   Choose the database engine for the new instance: SQL Server, Azure SQL DB, Azure SQL MI, PostgreSQL, MariaDB / MySQL, Oracle ADB, or Oracle DB. Click an engine card to proceed.
4. 4
   Step 2 · Connection Details

   Enter a friendly Instance Name, Username, and Password. For SQL Server / Azure / MariaDB / PostgreSQL: also enter Host, Port, and Database name. For Oracle ADB: enter the TNS Connect String (from tnsnames.ora) and optionally drag-and-drop a Wallet zip and its password.
5. 5
   Step 3 · Confirm & Add

   Review the summary. Click Test Connection to verify connectivity before saving, then click Add Instance. The wallet is uploaded automatically if one was provided. The dashboard refreshes and switches to the new instance immediately.

Oracle ADB uses mTLS wallet-based authentication. No Oracle Instant Client is required — DPSMF connects in thin mode using the oracledb driver. Follow the steps below to connect an Always Free or paid ADB instance.

1. 1
   Download the Wallet from OCI

   In the OCI Console, go to Autonomous Database → your DB → Database Connection → Download Wallet. Set a wallet password (e.g. MyWallet2026!) and save the zip. You will need this password when adding the instance in DPSMF.
2. 2
   Select Oracle ADB engine

   In the Add Instance wizard, click the Oracle ADB card. The form switches to Oracle mode: standard host/port fields are replaced with a single TNS Connect String field and a wallet upload zone.
3. 3
   Enter connection details

   Instance Name — a friendly label (e.g. MediBill Oracle ADB)
   Username — ADMIN (or a least-privilege monitoring user)
   Password — the DB ADMIN password set during ADB provisioning
   TNS Connect String — the alias from tnsnames.ora inside the wallet zip, e.g. dpsmf_tp. Use the _tp or _low alias for monitoring workloads.
4. 4
   Upload the Wallet

   Drag and drop the wallet .zip file onto the upload zone, or click Browse. Enter the Wallet Password you chose in step 1. DPSMF extracts ewallet.pem and tnsnames.ora automatically and stores them securely on the server.
5. 5
   Add Instance

   Click Add Instance. The wallet is uploaded immediately after the instance record is created. The collector picks up the new instance within 60 seconds and begins streaming metrics to the dashboard. Oracle ADB metrics include CPU, memory (SGA+PGA), sessions, wait classes, schema sizes, index health, and security posture.

A shadow user (shadow identity) is a dedicated SQL Server login that DPSMF uses for one specific category of operation on an instance. Instead of a single high-privilege service account that can do everything, you create up to five focused logins — one per function. Each login is granted only the permissions required for its role.

DPSMF stores the login name and (optionally) the credential for each shadow identity, validates that the login exists in sys.server_principals, and reads back the server permissions it has been granted. This gives you a live, audited map of exactly what each functional identity can see and do.

The traditional approach to monitoring is a single service account, often granted sysadmin or broad db_owner rights across every database. Shadow identities eliminate the four principal failure modes of that model:

DPSMF validates each shadow identity live against sys.server_principals and reads back its effective server permissions. This means misconfigured logins (e.g., missing VIEW SERVER STATE) are caught and surfaced in the interface before they silently fail during a collection cycle.

Run the T-SQL below on each SQL Server instance you want to shadow. You only need to create the logins for the categories you intend to use. Replace the placeholder passwords with strong, unique credentials.

-- ── MONITOR (metric collection — read-only) ────────────────────────────
CREATE LOGIN dpsmf_monitor WITH PASSWORD = 'MonitorPass2026!', CHECK_POLICY = ON;
GRANT VIEW SERVER STATE TO dpsmf_monitor;
GRANT VIEW ANY DEFINITION TO dpsmf_monitor;  -- needed for index/query health

-- ── TUNER (index + statistics work) ────────────────────────────────────
CREATE LOGIN dpsmf_tuner WITH PASSWORD = 'TunerPass2026!', CHECK_POLICY = ON;
-- Grant ALTER on each target database, not server-wide:
USE [YourDatabase]; CREATE USER dpsmf_tuner FOR LOGIN dpsmf_tuner;
ALTER ROLE db_owner ADD MEMBER dpsmf_tuner;  -- or a custom role with ALTER INDEX

-- ── CONFIG (server-level settings via sp_configure) ─────────────────────
CREATE LOGIN dpsmf_config WITH PASSWORD = 'ConfigPass2026!', CHECK_POLICY = ON;
GRANT ALTER SETTINGS TO dpsmf_config;
GRANT VIEW SERVER STATE TO dpsmf_config;

-- ── SECURITY (audit login hygiene and permission maps) ───────────────────
CREATE LOGIN dpsmf_security WITH PASSWORD = 'SecurityPass2026!', CHECK_POLICY = ON;
GRANT VIEW ANY DEFINITION TO dpsmf_security;
GRANT VIEW SERVER STATE TO dpsmf_security;

-- ── MAINTENANCE (DBCC, integrity, cleanup) ──────────────────────────────
CREATE LOGIN dpsmf_maint WITH PASSWORD = 'MaintPass2026!', CHECK_POLICY = ON;
-- Grant db_owner (or custom maintenance role) per database:
USE [YourDatabase]; CREATE USER dpsmf_maint FOR LOGIN dpsmf_maint;
ALTER ROLE db_owner ADD MEMBER dpsmf_maint;

1. 1
   Open the Instance

   From the dashboard, select the SQL Server instance you want to configure. Click Settings in the top instance toolbar, then choose the Shadow Identities tab.
2. 2
   Add a Shadow Identity

   Click Add Shadow Identity. In the slide-in form, choose a Category from the dropdown (monitor, tuner, config, security, or maintenance). Enter the SQL Login name exactly as created on the SQL Server (e.g. dpsmf_monitor). Optionally enter the Password — required if DPSMF will use this identity to connect actively, not needed for audit-only registration.
3. 3
   Save the Shadow Identity

   Click Save. DPSMF stores the login name and encrypts any credential using AES-256-GCM. The entry appears in the shadow identity list with a Not validated badge.
4. 4
   Validate Against SQL Server

   Click Validate next to the new entry. DPSMF connects to the SQL Server instance using its primary collector credential, queries sys.server_principals to confirm the login exists and is enabled, then reads its effective permissions from sys.server_permissions. The badge updates to Validated ✓ with a permissions summary, or shows a specific error if the login is missing or disabled.
5. 5
   Repeat for Each Category

   Add one entry per function you use. Each category can only have one shadow identity per instance — re-saving an existing category updates it (upsert). The validation badge is automatically cleared when a shadow identity is edited, requiring re-validation.

1. 1
   Provision the ADB (if not done)

   In OCI Console go to Oracle Database → Autonomous Database → Create Autonomous Database. Choose Transaction Processing, Always Free if applicable. Set an ADMIN password. Wait for status to show Available (usually 2–3 minutes).
2. 2
   Download the Wallet

   On the ADB detail page click Database Connection → Download Wallet. Enter a wallet password (e.g. MyWallet2026!) and save the .zip file. Do not unzip it — DPSMF handles that.
3. 3
   Find your TNS alias

   Open the zip and read tnsnames.ora. It lists 5 aliases: high, medium, low, tp, tpurgent — all prefixed with your DB name. Use the _tp alias for DPSMF monitoring (transaction processing profile, low priority).
4. 4
   Add Instance in DPSMF

   Go to + Instance → Oracle ADB. Fill in: Instance Name (any label), Username (ADMIN), Password (your ADB ADMIN password), TNS Connect String (e.g. mydb_tp). Drop the wallet zip on the upload zone and enter the wallet password. Click Add Instance.
5. 5
   Verify on Dashboard

   Within 60 seconds the new instance appears in the instance selector. Switch to it — you should see CPU, SGA/PGA memory, sessions, wait events, and schema sizes populating. If the instance shows a red connection badge, check that the ADB is not paused in OCI and that the TNS alias matches exactly what is in tnsnames.ora.

Using ADMIN for monitoring works but gives DPSMF full DBA access. For production use, create a dedicated read-only monitoring user:

-- Run as ADMIN in SQL*Plus, SQLcl, or OCI Database Actions
CREATE USER dpsmf_mon IDENTIFIED BY "MonitorPass2026!";
GRANT CREATE SESSION TO dpsmf_mon;
GRANT SELECT ANY DICTIONARY TO dpsmf_mon;
GRANT SELECT ON V_$SESSION TO dpsmf_mon;
GRANT SELECT ON V_$OSSTAT TO dpsmf_mon;
GRANT SELECT ON V_$SGAINFO TO dpsmf_mon;
GRANT SELECT ON V_$PGASTAT TO dpsmf_mon;
GRANT SELECT ON V_$SYSTEM_WAIT_CLASS TO dpsmf_mon;

Then use dpsmf_mon as the Username and its password when adding the instance in DPSMF.

1. 1
   Go to Settings → Users → Add User

   Enter a username, email address, and temporary password (minimum 8 characters).
2. 2
   Assign a Role

   Choose dba, viewer, or readonly. Role controls what actions the user can perform across all DPSMF screens.
3. 3
   Send Credentials

   Share the temporary password with the user. They can change it after first login via Profile → Change Password.

Go to Settings → Users, find the user, and click Reset Password. Enter a new temporary password (min 8 characters). The user will be required to change it on next login.

Go to Settings → License → Activate and enter your license key. Keys take the format DPSMF-XXXXXX-XXXXXX. After activation, the license manager shows the tier, expiry date, instance count, and days remaining.

DPSMF does not require you to manually describe your topology. When the collector agent connects to a SQL Server instance for the first time, it automatically discovers and reports:

• Server identity — hostname, SQL Server version, edition, and build number
• Hardware profile — CPU count, NUMA nodes, and physical memory
• Instance configuration — startup time, collation, and compatibility level
• All online databases — size, recovery model, auto-shrink settings, and page verify options

This information is sent on the first push and kept current on every subsequent push. The Global Dashboard populates automatically — no manual configuration of topology is required.

The current deployment model is one collector agent per SQL Server instance. Each agent runs as a Windows service on the host machine (or any machine with network access to port 1433) and pushes metrics to DPSMF every 60 seconds.

# 1. Download and extract dpsmf-agent-v2.zip from dpsmf.ai/dpsmf/downloads/
# 2. Edit .env with your SQL Server credentials
npm install
node dpsmf-agent.js          # test — verify Push OK in output
node dpsmf-agent.js --install  # register as Windows Service (auto-starts on reboot)

The next evolution of DPSMF deployment is a single discovery agent that scans a network segment, identifies all SQL Server instances automatically, and registers them with the dashboard — no per-instance configuration required.

Planned capabilities:

• Network scan — discovers SQL Server instances by port and service name across a subnet
• Auto-registration — each found instance is registered in DPSMF and assigned to the correct tenant automatically
• AG/cluster topology mapping — detects Always On groups and failover clusters, rendering them as a single logical unit in the dashboard with primary/secondary relationship intact
• Zero per-instance config — one agent key, one installer, the rest is automatic

DPSMF Enterprise supports SAML 2.0, compatible with Okta, Azure Active Directory, Google Workspace, and any SAML 2.0-compliant identity provider. Once configured, users authenticate through your IdP — DPSMF issues a session token and never handles passwords directly.

1. 1
   Navigate to Settings → Security & Authentication

   Only Platform Admins and Admins can access this section.
2. 2
   Paste your IdP Metadata URL

   Your identity provider will supply a metadata URL (e.g. https://your-org.okta.com/app/metadata). DPSMF fetches the certificate and endpoint URLs automatically.
3. 3
   Map Attributes

   Map the IdP attributes to DPSMF fields: email (required), name (optional), group (optional — used to auto-assign roles). Example: IdP group dba-team → DPSMF role dba.
4. 4
   Test Before Enforcing

   Click Test SSO Login. A new tab opens the IdP login flow. Confirm your session is created correctly before toggling Enforce SSO — once enforced, password login is locked out for all non-platform-admin accounts.
5. 5
   Toggle Enforce SSO

   Switch Enforce SSO on. All future logins route through your IdP. Existing sessions remain valid until they expire.

DPSMF has two layers of access control. Global roles (Viewer, Analyst, DBA, Admin) set what actions a user can perform. Instance scoping controls which connected SQL Server instances they can see. The two layers combine: a DBA scoped to Instance A cannot see Instance B, even if they have full DBA permissions globally.

Scoping is enforced at the API layer — not just the UI. A scoped user cannot retrieve data for out-of-scope instances via direct API calls.

1. 1
   Navigate to User Management

   Go to Settings → User Management. Only Admins and Platform Admins can modify user scopes.
2. 2
   Click Edit on the user

   The user edit modal opens. Scroll down to the Instance Access section.
3. 3
   Set per-instance permissions

   Each connected instance has a dropdown with three options: No Access (instance is hidden entirely), Read Only (can view metrics and alerts, cannot change settings), Full Access (inherits their global role permissions on this instance).
4. 4
   Save

   Changes take effect immediately. The user does not need to log out — their next API request will use the updated scope.

1. 1
   Go to Alert Manager → Channels tab

   Click Add Channel.
2. 2
   Select the channel type and paste the URL or key

   For Slack and Teams: the Incoming Webhook URL from your workspace settings. For PagerDuty: the 32-character Routing Key from your service integration page.
3. 3
   Choose which severity levels trigger this channel

   Options: Info, Warning, Critical. You can configure multiple channels — for example, Warning and Critical to Slack, Critical only to PagerDuty.
4. 4
   Click Send Test

   DPSMF sends a test payload immediately. Confirm receipt before saving.

Global thresholds apply to every connected instance. In most enterprise environments that causes two problems: production alerts are missed because thresholds are tuned for dev, or dev instances generate constant noise because they are held to production standards.

Per-instance overrides let you set a PLE critical threshold of 300 on production and a PLE warning threshold of 50 on a dev box — each instance is judged against its own context.

1. 1
   Open the Instance Detail page

   From the dashboard, click the instance name or navigate to Settings → Instances and select the instance.
2. 2
   Click the Thresholds tab

   A table lists every monitored metric, its global default warning and critical values, and an editable override column.
3. 3
   Enter override values

   Type a value in the Warning Override or Critical Override column for any metric. Leave blank to inherit the global default. Changes are saved per row.

Every significant action in DPSMF writes a row to the audit log: logins, logouts, failed login attempts, user creation and modification, role changes, instance connections and disconnections, alert rule changes, Sentinel AI queries, and configuration changes. Each row records the user, timestamp, action type, affected resource, and originating IP address.

1. 1
   Navigate to Audit Log

   From the main nav, go to Audit Log.
2. 2
   Click Export (top-right)

   A date range picker opens. Select the start and end dates for the export window.
3. 3
   Choose format

   CSV — raw rows suitable for SIEM ingestion or spreadsheet analysis. PDF — formatted compliance report with DPSMF logo, date range, record count, and a SHA-256 hash footer for tamper evidence.
4. 4
   Download

   The file is generated server-side and downloaded immediately. No copy is retained by DPSMF after download.

The status page at dpsmf.ai/status shows current health and 90-day uptime history for each DPSMF service component: the Collector engine, the API layer, Sentinel AI, the Knowledge Graph engine, and the web application. No login is required — share the URL with your IT team or include it in vendor questionnaires.

Enterprise customers can subscribe to status notifications directly from the status page. Delivery options: email, SMS, or webhook. Notifications fire on any status change — component degradation, incident open, incident resolved, and maintenance start/end.