Operational instructions

Page, Installation and Action Guide

Use this page to know how the on-prem installation is laid out, which rights each server type needs, where each signal belongs, which actions write to a database and how to verify the result after clicking.

Actions and risk All pages

Rule 1 Data Quality decides trust

If a dashboard is empty or too green, check source coverage before believing the signal.

Rule 2 Forecast is for future pressure

Use Forecast when you need days-to-risk, growth trend, log/file pressure and preventive actions.

Rule 3 Every write action needs verification

After any button that changes SQL or app policy, refresh the evidence page and prove the risk moved.

Rule 4 Everything is installed on-prem

The web app, admin database, secrets and report scheduler run locally. External targets are monitored through registered connections.

Installation model on-prem first, monitored targets second

Application host

Install the web app on an on-prem Windows/IIS or Windows Service host inside the network that can reach SQL Server, Azure SQL endpoints and Oracle listeners.

Admin database

dbNexia_ADMIN_DB is the on-prem control plane and central evidence repository. It stores server inventory, protected connection metadata, users, license state, report schedules, incident cases, alert rules and source-separated SQL Server/Oracle history. Every synchronized source remains attributable to its registered server.

On-prem SQL Server targets

When adding a normal SQL Server, the app creates or updates the standard dbNexia_DB collector package. It is a short-lived collection buffer: rows are copied to central admin storage, acknowledged and then locally retained only for the configured buffer period.

Azure SQL targets

Azure SQL Database is registered as a database endpoint only. The app does not install dbNexia_DB in Azure SQL; Azure Monitor, diagnostics and auditing provide cloud-side telemetry where needed.

Oracle targets

Oracle is registered read-only by default. No Oracle tables, packages, jobs or schemas are installed; the app reads catalog and performance views and stores snapshots in the on-prem admin database.

Scheduled work

Report delivery and background refresh depend on the on-prem app process staying alive. Configure the host so it starts automatically and does not idle out.

Server rights minimum access per added server type

On-prem SQL Server

What is installed: The app creates or updates the standard dbNexia_DB collector package on the monitored SQL Server. Collected rows are synchronized into a source-specific schema in the central admin database; the target keeps only the configured short local buffer.
Minimum read/preflight rights: For first add/sync: sysadmin is required by the current preflight because the app creates/updates dbNexia_DB and deployment objects. For ongoing monitoring: read access to dbNexia_DB plus msdb backup/job history and VIEW SERVER STATE for live workload, volume, TempDB and waits. SQL Agent Jobs also reads msdb job metadata and verifies job owner/sysadmin before writing.
Optional write/action rights: SQL Agent start permission for job actions; SQL Agent job create/update/delete rights for SQL Agent Jobs; backup-folder validation through SQL Server when backup plans are configured; ALTER DATABASE for pre-grow and database options; ALTER INDEX/CREATE INDEX/DROP INDEX/UPDATE STATISTICS/ALTER TABLE for Database Health and Workload Lab fixes; permission grants when the diagnostic-permission action is used.
Main signals unlocked: Centrally synchronized EventLog, AuditLog, dbsizes, ServerMetrics, index/table history and inventory; live SQL Agent, backup, Query Store, waits, blocking, deadlocks, TempDB and volume state where freshness requires direct reads.

Azure SQL Database

What is installed: The on-prem app registers one database endpoint. No dbNexia_DB objects are created in Azure SQL and no agent/schema package is installed there.
Minimum read/preflight rights: A SQL login or Entra-backed user that can connect to the target database, read catalog views, read Query Store where used and read database-scoped DMVs. Azure diagnostics/auditing must be enabled separately in Azure Monitor / Log Analytics if those signals are required.
Optional write/action rights: Only grant write rights for actions you want to allow, such as ALTER DATABASE scoped options, CREATE/DROP INDEX or UPDATE STATISTICS. There is no SQL Agent on Azure SQL Database.
Main signals unlocked: Database-scoped catalog and Query Store signals from the database, plus Azure Monitor / Log Analytics for audit, errors, timeouts, blocks, deadlocks and metrics.

Oracle

What is installed: The on-prem app registers the Oracle target read-only by default. No schema, package, job or table is created in Oracle. Oracle snapshots are stored in the on-prem admin database.
Minimum read/preflight rights: A service user that can connect through host/service, TNS or EZConnect and read the required catalog/performance views: V$DATABASE, V$INSTANCE, V$SESSION, V$SQL, V$SQL_PLAN, V$DIAG_ALERT_EXT, V$RMAN_BACKUP_JOB_DETAILS, V$TEMP_SPACE_HEADER, DBA_DATA_FILES, DBA_FREE_SPACE, DBA_TEMP_FILES, DBA_TABLES, DBA_TAB_STATISTICS, DBA_INDEXES, DBA_IND_STATISTICS, DBA_IND_PARTITIONS, DBA_SEGMENTS, DBA_OBJECTS and DBA_SCHEDULER_JOB_RUN_DETAILS. Use SELECT_CATALOG_ROLE or explicit SELECT grants according to local policy.
Optional write/action rights: Only if Oracle actions should run: EXECUTE on DBMS_STATS for gather stats, EXECUTE on DBMS_SCHEDULER or job-owner rights for RUN_JOB, ALTER privileges on selected objects for COMPILE/ALTER INDEX REBUILD/COALESCE. Keep these separate from the read-only service user if production policy requires it.
Main signals unlocked: Tablespaces, TEMP, active sessions, blocking, long-running SQL, full scans, stale/locked statistics, invalid objects, unusable indexes, Scheduler failures, RMAN freshness, alert errors and deadlocks from alert text.

Risk model what the labels mean before clicking

Read-only

Filters, navigation, scans or evidence review. No intended SQL/app configuration change.

Medium

Starts existing jobs or changes app policy. Usually reversible, but can create load or change alert behavior.

High

Changes target database files, indexes, statistics, constraints, configs, audit/event collection or permissions.

Critical

Changes inventory, schema sync, user access or security/licensing foundations. Use admin review.

Daily operating flow from evidence trust to action

1Status

Confirm registered servers and collectors are reachable.

2Data Quality

Check missing or stale sources before interpreting green pages.

3Action Center

Choose the highest operational priority and owner route.

4Evidence page

Open Forecast, Reports, Database Health, Backup Readiness, Incidents or Server Overview.

5Action and verify

Run only the justified action, then prove the signal changed.

Scheduled report delivery the on-prem host must stay running

Scheduled reports are saved in the application database and processed by the web app background service. The browser does not send scheduled mail.
If the hosting platform stops or idles the web app process, the background service is also stopped. Reports can then be delayed until someone opens the app or the host starts it again.
For IIS, set the application pool Start Mode to AlwaysRunning, set Idle Time-out to 0, and enable Preload on the site/application.
For Windows Service/Kestrel hosting on-prem, configure the service Startup type as Automatic and set recovery actions to restart the service on failure.
After scheduling a report, open Admin / Report Delivery Settings and verify the next run. After the first scheduled time, confirm Last status shows the report was sent.

Action catalogue what each button can change

Action	Where	Risk	What it writes	Safe use	Verify after
Pre-grow database/log file	Forecast	High	ALTER DATABASE MODIFY FILE / size growth on target database.	Use when forecast shows near-term fill risk and disk reserve, max-size and autogrowth checks pass.	Forecast reloads; confirm file free percent, volume reserve and queue priority changed.
Start SQL Agent / Oracle Scheduler job	Dashboard, Forecast, Database Health	Medium	Starts an existing SQL Agent job or Oracle Scheduler job on the selected target.	Use for failed or urgent maintenance/log jobs after checking last failure and current workload.	Check SQL Agent or Oracle Scheduler job history and related page signal after the job finishes.
Index rebuild/reorganize/coalesce	Reports, Database Health, Workload Lab	High	ALTER INDEX operations in SQL Server or Oracle; can use CPU, IO, blocking time, transaction log, redo/undo and TEMP.	Use in a maintenance window or when impact is acceptable and fragmentation/index evidence is current.	The initiating page verifies/reloads after completion. Confirm the open row disappears; use Index history for retained run/end timestamps. A later collector may create a new row only if fresh measurement still exceeds policy.
Create or drop index	Database Health, Workload Lab	High	Changes physical database design.	Create only for recurring workload and after overlap/write-cost review. Drop only after rare-report and release review.	Compare workload metrics, query plans and missing/unused-index rows after the change.
Update or gather statistics	Database Health, Workload Lab, Reports	Medium	SQL Server UPDATE STATISTICS or Oracle DBMS_STATS gather table/index statistics.	Use when stale statistics explain bad estimates or regressions.	The live stale-stat check is rerun and matching rows are removed only when resolved. SQL Server table metadata is also stamped locally and centrally; compare estimates, duration, reads or memory grants after plans recompile.
Compile Oracle invalid object	Database Health	Medium	ALTER object COMPILE on an Oracle package, procedure, function, trigger, view or type.	Use after checking dependency errors and when compiling will not hide a deployment issue.	Rerun Database Health or Content View invalid objects and confirm the object is VALID.
Validate constraints	Database Health	High	ALTER TABLE WITH CHECK CHECK CONSTRAINT.	Use when the database can tolerate validation load and possible validation failures.	Finding should resolve; if validation fails, fix data before trusting the constraint.
Change database option/permission	Database Health	High	ALTER DATABASE or GRANT diagnostic permissions.	Use only when the recommendation matches the operational policy.	Rerun scan and confirm option/permission state.
Save alert rules	Alert Rules	Medium	Rewrites dbo.APP_ALERT_RULES in the admin database.	Use when thresholds, owners, channels or suppression are wrong for operations.	Refresh Action Center and confirm classification/routing is correct.
Save report schedule	Report Center	Medium	Creates or updates APP_REPORT_SCHEDULES in the application database.	Use only after SMTP and recipient lists are configured. Scheduled delivery requires the web app host to run Always On.	Open Admin / Report Delivery Settings and confirm next run, then check last status after the first scheduled time.
Save configs row	Server Configurations	High	Updates target server dbNexia_DB.dbo.configs.	Use after validating config_query and knowing which collector/procedure consumes the value.	Run dependent collector or page and confirm behavior changed.
Save audit/event config	AuditEventLogConfig	High	Updates procedure/config, syncs and executes it on selected servers.	Use when log/audit collection should change; consider noise, storage and security coverage.	Check sync result, Reports logs, Incidents, Forecast signal coverage and Data Quality.
Create/update/delete SQL Agent job	SQL Agent Jobs	High	Creates, updates or deletes msdb SQL Agent jobs, job steps and schedules on selected on-prem SQL Server targets.	Use after selecting the intended targets, checking owner/sysadmin preflight, backup folder availability and schedule overlap. Delete only application-managed jobs from this page.	Review each server result, expand Job inventory, confirm enabled/schedule/owner state, then check SQL Agent job history after execution.
dbNexia_DB sync apply	dbNexia_DB Sync	Critical	Creates/alters target database objects and procedures.	Preview first, select intended servers, apply during controlled admin window.	Check applied/skipped/failed actions, then Status and Data Quality.
Add/delete server	Servers	Critical	Changes registered server inventory. On-prem SQL Server add can create/update dbNexia_DB; Azure SQL and Oracle add only encrypted telemetry metadata.	Use with verified connection, license capacity, required permissions and correct environment/server type.	Test connection, open Status, Reports and Data Quality for the server.
Manage users/passwords/roles	Users	Critical	Changes app identities and authorization.	Use only for approved access changes.	Validate login and role access immediately.
Import license	License	Medium	Updates license state used by server registration.	Use a trusted license response file/text for this installation.	License page should show valid state and correct server limit.

All pages purpose, actions, data and verification

Operations Operations Cockpit

Medium

What it is for: First operational screen after sign-in with estate summary, priority queues, backup/job/runtime/security signals and direct links to the owning evidence pages.
Actions on the page: Filter by server, open server Dashboard, Forecast, Server Overview or report evidence, and start selected SQL Agent/Oracle Scheduler jobs where the row exposes an approved action.
Data used: Registered servers, SQL Agent/Oracle Scheduler history, backup/RMAN history, EventLog, AuditLog, deadlocks, blocking, long requests, source freshness, volume and health telemetry.
How to verify: After acting from a linked row, open the target Dashboard/evidence page and confirm job history, Action Center and Data Quality reflect the change.

Operations Dashboard

Medium

What it is for: Estate overview for the selected SQL Server, Azure SQL or Oracle target: health, jobs, backups, runtime pressure and action signals.
Actions on the page: Start selected SQL Agent job or Oracle Scheduler job from the job failure panel when permissions allow it.
Data used: SERVERS, SQL Agent/Oracle Scheduler history, backup/RMAN history, event/alert signals, drive/tablespace and health telemetry.
How to verify: Refresh Dashboard, confirm job history changed and check Action Center if the signal remains.

Operations Status

Read-only

What it is for: Connectivity, collection freshness and repository/source visibility.
Actions on the page: No direct server write action. Use it to decide whether data can be trusted.
Data used: Registered server metadata, connection checks, collector timestamps and source health.
How to verify: A green Status page means the evidence pipeline is usable; it does not prove the databases are healthy.

Operations Action Center

Read-only

What it is for: Prioritized operational queue with severity, score, owner, SLA, rule id and next action.
Actions on the page: Navigate to the evidence page named in Source Page. No direct execution here.
Data used: Alert Rules plus backup, drive, job, event, deadlock, blocking, long request and telemetry-gap signals.
How to verify: After fixing a root cause, refresh Action Center and confirm the item is gone or downgraded.

Operations Server Overview

Read-only

What it is for: Server-level situation view: state, pressure, forecast, evidence and actions to break the trend.
Actions on the page: Filter, sort, inspect evidence and jump to deeper pages.
Data used: Backups, drives, jobs, runtime events, long requests, health, tempdb, source health and growth trend.
How to verify: Use it after a fix to confirm server state, forecast text and action count improved.

Operations Data Quality

Read-only

What it is for: Shows whether pages have enough current evidence to make reliable conclusions.
Actions on the page: No direct write action; fix collector, permission or repository gaps outside this page.
Data used: Data source availability, row freshness, collector health and repository coverage.
How to verify: If a dashboard is empty or too green, this page must be checked first.

Operations Database Health

High

What it is for: Deep database scan for SQL Server and Oracle indexes, statistics, storage, unsafe options, invalid objects, RMAN/Scheduler signals and permissions.
Actions on the page: Run scan, then run individual approved fixes: SQL Server create/drop/rebuild/reorganize index, update statistics, validate constraints, set fixed file growth, enable auto stats, disable TRUSTWORTHY, grant diagnostics; Oracle gather stats, compile objects, rebuild/coalesce indexes and run Scheduler jobs.
Data used: Live target SQL Server DMVs/sys catalogs, centrally synchronized dbNexia_DB history, and Oracle catalog/performance views.
How to verify: The page reruns live checks after execution. A resolved row is removed immediately; central index/statistics action metadata is updated at the same time and background sync repairs any interrupted update.

Operations Backup Readiness

Read-only

What it is for: Backup age, log-chain or archive-log exposure, recovery model/log mode risk and restore-readiness evidence.
Actions on the page: No direct backup execution. Use the page to choose which SQL backup job, Oracle RMAN job or restore validation must be handled.
Data used: SQL Server msdb backup history, Oracle V$RMAN_BACKUP_JOB_DETAILS, database metadata, recovery/log mode and policy thresholds.
How to verify: After backup/job repair, refresh and confirm full, diff/log or RMAN evidence is inside policy.

Operations Alert Rules

Medium

What it is for: Policy catalogue for what becomes Critical, High or Watch in Action Center and incident views.
Actions on the page: Save rule changes, enable/disable rules, edit severity, threshold, owner, notification route, suppression and runbook; reset defaults.
Data used: dbo.APP_ALERT_RULES in the admin database plus built-in default policy.
How to verify: Refresh Action Center and affected pages to confirm changed thresholds classify signals as intended.

Prediction Forecast

High

What it is for: Forward-looking capacity and pressure prediction for files, logs, volumes, jobs, backups, tempdb, events and audit signals.
Actions on the page: Pre-grow database/log files with disk, max-size and autogrowth checks; start linked SQL Agent jobs such as maintenance/log processing; navigate action queue to evidence rows.
Data used: Database file history, live sys.master_files, volume telemetry, SQL Agent jobs, backups, event logs, audit logs, deadlocks, blocking, source health and resource pulse.
How to verify: The action reloads the page. Confirm the database/file is removed or downgraded in Forecast action queue and file list.

Prediction Incidents

Read-only

What it is for: Groups operational incidents across errors, security signals, blocking, deadlocks and data gaps.
Actions on the page: Filter, inspect, correlate and open supporting evidence. No direct execution.
Data used: EventLog, AuditLog, SQL errors, deadlocks, blocking, jobs, long requests and source gaps.
How to verify: Use after a fix to confirm repeats stop in the selected lookback window.

Prediction Workload Lab

High

What it is for: SQL Server workload diagnosis for waits, Query Store regressions, live requests, plan cache, missing indexes and stale statistics. Oracle targets are listed and routed to matching Oracle workload reports.
Actions on the page: Analyze SQL Server workload, copy evidence/SQL, verify rows, and run approved fixes for executable workload rows when admin/moderator access allows it. For Oracle, use the direct links to sessions, blocking, table statistics, index health and Database Health.
Data used: SQL Server Query Store, DMVs, plan cache, missing-index DMVs, statistics properties and dbNexia_DB metadata; Oracle V$SESSION/V$SQL and catalog views through linked report pages.
How to verify: Use Verify resolved or rerun Analyze workload for SQL Server. For Oracle, rerun Content View or Database Health and confirm the row changed.

Reports Report Center

Medium

What it is for: Build, export and schedule operational reports for mail delivery.
Actions on the page: Export report files and save scheduled deliveries that run from the web app background service.
Data used: Current report criteria, registered server evidence, recipient lists and report delivery settings.
How to verify: After saving a schedule, check Admin / Report Delivery Settings for next run and last status. The host must be Always On for reliable delivery.

Reports Reports

High

What it is for: Raw evidence workspace for SQL Server and Oracle logs, audits, backups, jobs, indexes, tables, database/tablespace sizes and growth charts.
Actions on the page: Filter/sort/search report rows, load growth charts, view SQL Server index history, run controlled SQL Server index actions where enabled, and open Oracle sessions, blocking, Scheduler, RMAN, table statistics, index health, full scans, TEMP and tablespace reports.
Data used: Central per-server EventLog/AuditLog/index/table/growth history, central operational job/backup cache, and live Oracle catalog/performance reports where appropriate.
How to verify: A completed SQL Server index candidate disappears from the open list immediately while its timestamps remain in Index history. Oracle actions reload the live report; if a finding remains, review the returned verification message before retrying.

Administration Report Delivery Settings

Medium

What it is for: Configure SMTP, recipient lists and inspect scheduled report delivery status.
Actions on the page: Save mail settings, send SMTP test mail, manage recipient lists and review schedule next/last run status.
Data used: Application report delivery tables, encrypted SMTP password and saved schedules.
How to verify: Send a test mail after SMTP changes and confirm scheduled rows show expected next run. Configure Always On on the hosting platform before relying on scheduled delivery.

Administration Servers

Critical

What it is for: Register, test and remove monitored SQL Server, Azure SQL Database and Oracle targets.
Actions on the page: Add server, test connection, initialize or update target dbNexia_DB only for on-prem SQL Server, save encrypted connection metadata, delete server registration.
Data used: On-prem dbNexia_ADMIN_DB.dbo.SERVERS, license limits, encrypted credentials and target preflight checks.
How to verify: Run Test Connection, open Status and confirm Data Quality and reports populate for the server type.

Administration Server Configurations

High

What it is for: Edit per-server configs rows used by dbNexia_DB collectors and checks.
Actions on the page: Update a config row; config_query is validated as one read-only boolean condition before saving.
Data used: Target server dbNexia_DB.dbo.configs and column descriptions.
How to verify: Refresh Server Configurations and run the collector/page that depends on the changed config.

Administration SQL Agent Jobs

High

What it is for: Create, update, review and remove standardized maintenance jobs on registered on-prem SQL Server targets.
Actions on the page: Select SQL Server targets, build backup-plan, index maintenance, statistics, integrity, history cleanup or custom T-SQL jobs, set owner/schedule/retry/backup options, browse backup folders, save application-managed jobs, delete application-managed jobs and review read-only external jobs.
Data used: Registered SQL Server connections, msdb SQL Agent job metadata, job owner/sysadmin preflight, selected job definition and generated T-SQL.
How to verify: Review each server result, expand Job inventory, confirm application-managed jobs are listed first, then check msdb job history or Dashboard/Reports after the next run.

Administration Audit and Event Log Configuration

High

What it is for: Configure which Extended Events and Server Audit groups are written into dbo.INIT_AUDITLOG_EVENTLOG and deployed to targets.
Actions on the page: Search/filter events and audit groups, edit WHERE predicates, include/exclude production, save the source procedure, optionally run it on the admin server, sync only this procedure to selected servers, and optionally execute it on targets. Saving requires typing APPLY in the confirmation field; letter case does not matter.
Data used: SQL Server package event catalogue, audit group catalogue, current procedure text, selected registered servers and per-server dbNexia_DB sync/execution result.
How to verify: Review admin save result and per-server sync/execution rows, then confirm Reports, Incidents, Forecast and Data Quality show expected EventLog/AuditLog coverage without unexpected noise.

Administration dbNexia_DB Sync

Critical

What it is for: Compare and synchronize admin dbNexia_DB schema and programmable objects to registered on-prem SQL Server targets.
Actions on the page: Select target servers and object scopes, include/exclude production, allow or block destructive updates, optionally drop extra target tables, rewrite programmable objects, run a post-sync procedure, Preview selected changes and Apply selected changes. Apply requires typing SYNC in the confirmation field; letter case does not matter.
Data used: Admin source dbNexia_DB objects, selected object scopes, registered server connections, target dbNexia_DB state and per-object planned/applied/skipped/failed results.
How to verify: Always Preview first. After Apply, check every server action row, failed SQL preview/error details, then open Status, Data Quality and the consuming report/page for affected servers.

Administration Users

Critical

What it is for: Manage application users and access level.
Actions on the page: Save user details, set role, reset password, delete user, update profile.
Data used: ASP.NET Identity users and roles.
How to verify: Confirm the user can sign in with the intended role and cannot access pages outside that role.

Administration License

Medium

What it is for: Show license state, create request file and import a license response.
Actions on the page: Download request file, import license text/file.
Data used: License service storage and machine/request fingerprint.
How to verify: Refresh License and Servers; server count limits should match the imported license.

Reference Instructions

Read-only

What it is for: This guide: pages, data sources, action risks and verification rules.
Actions on the page: Read, navigate, and use links to the correct page.
Data used: Static guide plus current app route knowledge.
How to verify: Use it when unsure which page owns a signal or whether an action writes to SQL.

Reference Privacy

Read-only

What it is for: Static privacy and application information.
Actions on the page: No operational action.
Data used: Static page content.
How to verify: Not used for operational verification.

Data sources which evidence powers prediction and risk

EventLog / Oracle alert log Reports, Incidents, Forecast, Server Overview, Action Center

Runtime errors, login failures, CPU/memory warnings, Oracle alert errors and repeated event pulses.

AuditLog / Oracle unified audit Reports, Incidents, Forecast, security review signals

Security and operational audit patterns. Missing audit data can hide important risk.

SQL Agent / Oracle Scheduler history Dashboard, Forecast, Action Center, Server Overview, Reports

Failed, stale or urgent jobs and one-click SQL Agent or Oracle Scheduler start actions.

SQL Agent job definitions and schedules SQL Agent Jobs, Dashboard, Reports, Action Center

Shows enabled state, owner, schedule, application ownership, editable job metadata and whether a job can be changed safely from the app.

Backup / RMAN history Backup Readiness, Action Center, Server Overview, Forecast, Reports

SQL full/diff/log or Oracle RMAN freshness, restore-chain risk and RPO exposure.

Database file, volume and tablespace telemetry Forecast, Server Overview, Reports, Action Center

Days to fill, disk/tablespace reserve, autogrowth safety and pre-grow decisions.

Index/statistics metadata Database Health, Reports, Workload Lab

SQL fragmentation and table history are synchronized to the central per-server repository; live SQL/Oracle catalog checks verify stale, missing, unused or unusable objects and maintenance results.

DMVs, Oracle performance views and runtime health Workload Lab, Server Overview, Incidents, Data Quality

Waits, blocking, deadlocks, live requests, tempdb/TEMP, CPU and memory pressure.

Alert Rules Action Center, Incidents, Server Overview

Controls severity, threshold, owner, notification route and suppression.

Source health / Data Quality Every analysis page

Tells whether a green or empty page is trustworthy or only missing evidence.

Before actionminimum checklist

Confirm the selected server and database are correct.
Check Data Quality if the evidence looks empty, stale or too clean.
Read the risk label and the action text; know whether it writes to SQL, app policy or identity.
For High/Critical actions, confirm maintenance window, backup/rollback path and expected load.
Run Preview first when the page has a preview mode, especially dbNexia_DB Sync.

After actionprove it worked

Refresh the same page and confirm the row disappeared, downgraded or changed to completed.
For index/statistics actions, distinguish action completion from a fresh later finding: completed evidence stays in history, while only a new collector measurement above policy should reopen the row.
Open the evidence owner page named in Action Center or in the action result.
For SQL Agent or Oracle Scheduler actions, check job history and final step/status.
For file growth, check file size, free percent, volume free space and Forecast queue.
For policy/config changes, refresh Action Center, Data Quality and the page that consumes the policy.

Admin boundaries who should do what

Reader

Use evidence pages, reports, dashboards and instructions. No server, user or SQL write action.

Moderator

Can run approved operational actions and manage servers/configuration where the UI allows it.

Admin

Owns users, licensing, schema sync, audit/event configuration and critical platform changes.