Status
Are registered targets and repositories reachable?
Platform overview
One operating layer for database evidence, action and reporting.
dbNexia connects the pages database teams use to validate telemetry, prioritize work, investigate root causes, execute approved changes and prove outcomes.
Operational scope
9evidence source groups checked by Data Quality
7operational categories routed into Action Center
3database target types in the current platform
Coverage varies by platform and granted rights.
How the platform fits together
Six connected questions, not six disconnected dashboards.
The product keeps each stage linked to the evidence owner and the next operational decision.
Data Quality
Is the required evidence present and current?
Action Center
Which risk matters first, and who owns it?
Evidence page
What happened, where and with what impact?
Action & verify
Did the approved change remove or reduce the signal?
Report
What should be retained and communicated?
Product workspaces
Every page has a defined operational job.
Visitors can inspect the public demo in read-only mode. Write actions require an authorized role and the necessary target permissions.
01
Operations
Operations Cockpit & Server Overview
Start with estate and server posture: connectivity, jobs, backups, runtime pressure, resource pulse, growth trend and current action signals.
Decision
Which target needs attention and which evidence page should open next?
02
Trust
Status & Data Quality
Separate actual health from a dashboard that looks quiet because a collector, permission or source is unavailable.
Decision
Can the team trust the conclusions shown by downstream pages?
03
Priority
Action Center & Alert Rules
Convert raw operational signals into a governed queue with severity, score, category, owner, SLA, source page, runbook and suppression policy.
Decision
Which item should be addressed now, handled today or planned—and under which rule?
04
Investigation
Database Health, Workload Lab & Incidents
Investigate indexes, statistics, files, options, permissions, waits, Query Store, plan cache, live sessions, blocking, deadlocks and repeated runtime patterns.
Decision
What technical condition explains the risk and which change is justified?
05
Prevention
Forecast & Backup Readiness
Review database growth, file/log pressure, volume or tablespace reserve, failed or stale jobs and backup/RMAN freshness against selected policies.
Decision
Which capacity or recovery risk should be prevented before it becomes an incident?
06
Communication
Report Center & Report Browser
Turn current scope, policies and evidence groups into operational briefs, detail tables and scheduled or exported evidence packs.
Decision
What does management, a customer or the next DBA shift need to understand?
Evidence architecture
Data Quality checks the sources behind the conclusions.
dbNexia evaluates source availability and connects each missing source to the product views that become incomplete.
Open Data Quality in the demo ↗Runtime & audit
EventLog or Oracle alert evidence, AuditLog or unified audit, login failures, runtime errors, timeouts and security events.
Workload & concurrency
Live requests or sessions, waits, Query Store, plan cache, blocking, deadlocks and long-running SQL.
Jobs & recovery
SQL Agent or Oracle Scheduler history plus SQL backup history or Oracle RMAN evidence.
Capacity & temporary space
Database size history, files, volumes, tablespaces, TempDB or Oracle TEMP and current resource pressure.
Database object health
Indexes, statistics, constraints, options, permissions, invalid Oracle objects and maintenance metadata.
Target coverage
Capabilities follow the database platform.
Some evidence and actions are inherently platform-specific. The matrix below states those boundaries instead of implying identical coverage.
| Operational area | SQLSQL Server | AZAzure SQL Database | OROracle |
|---|---|---|---|
| Registration model | Server / instance | Individual database endpoint | Host, service, TNS or EZConnect |
| Installed on target | dbNexia_DB collector and schema objects | No dbNexia agent or schema package | Nothing; read-only registration by default |
| Workload evidence | DMVs, waits, Query Store, plan cache, live requests | Database-scoped DMVs and Query Store | V$SESSION, V$SQL, plan and catalog views |
| Jobs | SQL Agent history and optional start | No SQL Agent | Oracle Scheduler history and optional run |
| Recovery evidence | Full, differential and log backup history | Azure platform-specific recovery evidence | RMAN job history and archive-log posture |
| Capacity | Files, volumes, TempDB and growth history | Database-scoped storage and Azure metrics | Tablespaces, datafiles, TEMP and local snapshots |
| Optional actions | Files, indexes, statistics, options, constraints and jobs | Database-scoped options, indexes and statistics | Statistics, object compile, index maintenance and Scheduler jobs |
Controlled action model
Know what a button can change before clicking it.
The product classifies actions by operational risk and defines how the result should be verified.
Inspect and navigate
Filters, dashboards, evidence review and source navigation with no intended database or application change.
ReaderRun or change policy
Start an existing job, update statistics or change application policy such as alert rules and report schedules.
Moderator / AdminChange database state
Pre-grow files, alter indexes, validate constraints, update target configuration or grant diagnostic permissions.
Authorized operational roleChange platform foundations
Register targets, synchronize schema, manage identities or import licensing state under administrative review.
Admin01
→Confirm target, evidence quality and action risk.
02
→Run only the justified, authorized change.
03
Refresh the source page and prove the risk changed.
See the operating workflow
Evaluate dbNexia by the evidence path, not a feature checklist.
The public demo exposes the product in read-only mode with realistic operational signals and reports.