Clear answers for technical and commercial evaluation.

dbNexia is an on-prem database operations platform. It checks whether evidence can be trusted, turns operational signals into a prioritized Action Center, links them to investigation pages, supports controlled actions and retains the outcome for reporting.

Traditional monitoring often ends at a metric or alert. dbNexia continues through evidence confidence, severity, score, owner, SLA, source page, meaning, impact, recommended fix and verification. Monitoring remains part of the product, but the operating workflow is the differentiator.

No. SSMS and Oracle administration tools remain the hands-on tools for direct administration. dbNexia provides the cross-target evidence, prioritization, repeatable workflow, approved action paths and professional reporting around them.

AI-assisted product areas help with forecasting, incident grouping, workload triage, risk explanation and recommended next steps. The underlying technical evidence remains available for DBA validation; the product does not ask teams to accept an unexplained score.

It is designed for DBA teams, IT operations and technical leaders, as well as consultants and MSPs that need repeatable health reviews, incident evidence and customer-facing reports across database environments.

The current platform supports on-prem SQL Server instances, Azure SQL Database endpoints and Oracle targets. The operating workflow is shared, but evidence and available actions vary by platform.

No. SQL Server currently has the deepest collector and action coverage. Azure SQL is database-scoped and relies on Azure Monitor or Log Analytics for some cloud signals. Oracle uses approved catalog and performance views and is read-only by default.

Depending on deployment and permissions: dbNexia EventLog and AuditLog, SQL Agent history, msdb backup history, database size history, server metrics, Query Store, DMVs, waits, blocking, deadlocks, live requests, TempDB, indexes, statistics and volume metadata.

An individual database endpoint is registered. The platform reads database catalogs, database-scoped DMVs and Query Store where allowed. Azure diagnostics, auditing and Azure Monitor / Log Analytics must be configured separately when cloud-side audit, error, timeout, blocking, deadlock or metric signals are required.

With the required view access, the platform can use sessions, SQL, plans, alert-log evidence, RMAN history, Scheduler history, tablespaces, TEMP, table and index statistics, segments, invalid objects and index health. Oracle snapshots are stored in the on-prem admin database.

The web application runs on an on-prem Windows host using IIS or a Windows Service. The local dbNexia_ADMIN_DB stores registered target inventory, encrypted connection metadata, application users, license state, alert rules, report schedules and Oracle snapshot history.

When an on-prem SQL Server instance is added or synchronized, dbNexia can create or update dbNexia_DB and deploy the collector and schema objects used by evidence, reports and predictions.

Yes. The current add/sync preflight requires sysadmin while dbNexia_DB and deployment objects are created or updated. Ongoing monitoring can use narrower read access to dbNexia_DB and msdb plus VIEW SERVER STATE for live workload and server-level evidence. Optional actions require their corresponding permissions.

No. Azure SQL is registered as a database endpoint. dbNexia does not install an agent, local dbNexia database or schema package in the Azure SQL database.

No Oracle table, package, job or schema is installed. Oracle is registered read-only by default. The service identity reads approved catalog and performance views, and collected snapshots are stored in the local dbNexia admin database.

Registered connection metadata, including saved credentials where used, is stored encrypted by the on-prem control plane. Network reachability and the final service-account design remain part of the customer deployment review.

Reader reviews evidence and reports without intended write actions. Moderator can run approved operational actions where enabled. Admin owns users, licensing, synchronization and critical configuration.

Data Quality checks whether required evidence sources are available and current, identifies affected consumers and classifies target confidence. A quiet page should not be treated as healthy when its sources are partial or unavailable.

Signals can come from connectivity, backup/recovery, storage, jobs, runtime errors, concurrency, long queries and telemetry gaps. Policy determines severity, threshold, owner, SLA, notification route, suppression and runbook.

Depending on the target: indexes, statistics, constraints, files or tablespaces, unsafe options, diagnostic permissions, Oracle invalid objects, Scheduler/RMAN signals and other platform-specific findings.

For SQL Server it can triage live requests, waits, plan-cache cost, Query Store regressions, missing indexes and stale statistics. Oracle targets are routed to matching session, blocking, SQL, statistics and index-health reports.

Subject to platform, role and granted rights: start SQL Agent or Oracle Scheduler jobs, pre-grow SQL files, create/drop/rebuild/reorganize/coalesce indexes, update or gather statistics, validate constraints, compile Oracle objects, change selected options or permissions, save policy/configuration and synchronize dbNexia_DB objects.

Actions are classified as Read-only, Medium, High or Critical. The operator is expected to confirm the target and evidence, understand what will be written, use preview where available and refresh the evidence owner after the action to prove the signal changed.

No. Visitors can inspect pages, evidence and the action model in read-only mode. Operational and administrative actions require an authorized account and the necessary target rights.

The current Report Center includes Executive Weekly, Monthly Estate Review, Incident Review and Backup Board profiles. Users select scope, time window, policy thresholds, evidence groups and output before export or scheduling.

Depending on scope: operational verdict, estate score, priority actions, target inventory, recovery readiness, database growth, server metrics, temporary-space pressure, long-running queries, runtime groups, concurrency evidence, source gaps and audit groups.

Yes, if the on-prem application process remains running. The background service—not the browser—processes schedules. IIS should be configured for AlwaysRunning/preload with no idle timeout, or the Windows Service should start automatically and restart after failure.

After saving a schedule, check the next-run state in Report Delivery Settings. After the first scheduled window, confirm the last delivery status and investigate SMTP or host availability if it did not run.

Published pricing is per monitored SQL Server instance: $69 for 1–20, $64 for 21–50 and $59 for 51–100 instances per month. Estates with 101 or more instances use a custom volume agreement.

No. Unlimited platform users are included in the published SQL Server subscription tiers.

The public price table currently defines SQL Server instance pricing. A mixed target estate should be scoped directly so Azure SQL and Oracle coverage, deployment and commercial terms are explicit before purchase.

Standard onboarding is included in the published subscription. Larger estates can include rollout and governance planning; optional DBA advisory is available separately.

We map your target platforms, evidence sources, access boundaries and highest-friction workflows to the relevant product pages, demonstrate the evidence-to-action path and clarify deployment and pricing.