Deployment & access

Keep the dbNexia control plane inside your environment.

The application, admin database, encrypted target metadata, users, policies and report scheduler run on-prem. SQL Server, Azure SQL Database and Oracle are reached through registered connections.

Plan a technical walkthroughRead product guide ↗
Your network
dbNexiaWeb application
Admin DBInventory · policies · schedules
Encrypted registered connections
SQL ServerInstanceAzure SQLEndpointOracleService
Architecture

On-prem first. Monitored targets second.

Install the web application on a Windows/IIS or Windows Service host that can reach the database targets. The local dbNexia_ADMIN_DB acts as the control plane for registered servers, encrypted connection metadata, application identities, licensing, alert rules and report schedules.

Target-side deployment differs deliberately by platform. SQL Server can receive collector objects, while Azure SQL and Oracle use endpoint or read-only connection models.

01

Application host

Windows host running the web UI, authorization, background refresh and scheduled report delivery.

02

Admin database

Stores inventory, encrypted target metadata, policy, licensing, schedules and Oracle snapshot history.

03

Registered targets

Connections to SQL Server instances, Azure SQL database endpoints and Oracle services.

04

Evidence consumers

Status, Data Quality, Action Center, Forecast, Health, Workload, Reports and administration pages.

Target deployment models

What dbNexia installs—and what it does not.

These boundaries are central to deployment planning and should be clear before access is granted.

SQL

On-prem SQL Server

Provisioned target
What is installed

The app can create or update dbNexia_DB and deploy the collector/schema objects used by reports, evidence quality and predictions.

Core evidence

EventLog, AuditLog, SQL Agent, msdb backup history, size history, server metrics, Query Store, waits, blocking, deadlocks, TempDB and volume metadata.

Initial provisioningThe current add/sync preflight requires sysadmin while deployment objects are created or updated.
AZ

Azure SQL Database

Endpoint-only target
What is installed

No dbNexia database, agent or schema package is installed. One Azure SQL database endpoint is registered in the on-prem control plane.

Core evidence

Database catalogs, database-scoped DMVs and Query Store, supplemented by Azure Monitor / Log Analytics when audit, errors, deadlocks, blocking and metrics are required.

Platform boundaryAzure SQL Database has no SQL Agent. Job workflows therefore do not apply.
OR

Oracle

Read-only by default
What is installed

No Oracle table, package, schema or job is installed. The app reads approved catalog/performance views and stores snapshots in the local admin database.

Core evidence

Sessions, SQL, plans, alert log, RMAN, TEMP, tablespaces, table/index statistics, invalid objects, Scheduler history and object health.

Default postureKeep the service user read-only; optional write actions can use separately controlled privileges.
Permission planning

Grant visibility first. Add write rights only for approved actions.

The exact grants depend on platform, version, enabled telemetry and which operational actions the customer wants to expose.

TargetMonitoring / preflightOptional action rightsOperational note
SQLSQL ServerFirst add/sync: current preflight requires sysadmin.
Ongoing: read dbNexia_DB, msdb job/backup history and VIEW SERVER STATE for live workload, storage, TempDB and waits.		SQL Agent start; ALTER DATABASE; index create/drop/rebuild/reorganize; UPDATE STATISTICS; ALTER TABLE and selected diagnostic grants.Separate deployment-time privilege from the ongoing monitoring and action model where local policy requires it.
AZAzure SQLSQL or Entra-backed identity that can connect to the database and read catalogs, Query Store and database-scoped DMVs. Configure Azure diagnostics separately for cloud-side signals.Only chosen database-scoped actions, such as database options, index changes or statistics updates.No server-level agent and no dbNexia schema package is deployed.
OROracleService user with selected catalog/performance-view reads, using explicit grants or SELECT_CATALOG_ROLE according to policy.Optional DBMS_STATS, DBMS_SCHEDULER or selected object ALTER rights for gathering statistics, running jobs, compiling objects or maintaining indexes.Optional action rights can remain separate from the read-only service account.

A deployment review should validate the final grant script against the exact platform version, target topology and security policy.

Application authorization

Separate evidence access from operational change.

Database permissions decide what the target accepts. dbNexia roles decide which product workflows the signed-in user can reach.

01

Reader

Reviews dashboards, evidence pages, reports and instructions. No intended server, identity or database write action.

Evidence & reporting
02

Moderator

Runs approved operational actions and manages selected server or configuration workflows where the UI and target rights allow it.

Controlled operations
03

Admin

Owns users, licensing, schema synchronization, collection configuration and other critical platform changes.

Platform administration
Always running
24/7

Scheduled work depends on the application process.

The browser does not send scheduled reports. Background delivery and refresh need the on-prem application host to remain active.

Host operations

Configure the service for continuity.

01

IIS

Use AlwaysRunning start mode, disable idle timeout and enable application preload.

02

Windows Service / Kestrel

Use Automatic startup and configure recovery actions to restart after failure.

03

Verification

Confirm next-run state after scheduling and check last status after the first delivery window.

Practical rollout

Move from architecture review to trusted evidence.

  1. 1

    Map the estate

    Confirm target types, network routes, environments and licensing scope.

  2. 2

    Define evidence

    Select the telemetry needed for backups, runtime, workload, security and capacity.

  3. 3

    Approve access

    Separate initial provisioning, ongoing monitoring and optional action privileges.

  4. 4

    Register & verify

    Test connections, populate collectors and confirm Status and Data Quality.

  5. 5

    Set policy

    Review alert thresholds, owners, SLAs, suppression, SMTP and report recipients.

  6. 6

    Prove the workflow

    Follow one real signal through evidence, action, verification and reporting.

Deployment review

Bring your target topology and access policy.

We will map the product to your network, database platforms and operational boundaries before deployment.

Book technical walkthroughRead access FAQ