Privacy

Privacy and Data Handling

dbNexia DEMO is designed for database operations teams that need monitoring, forecasting, restore-readiness, database-health checks and incident prevention without losing control of operational data. This page explains what the application stores centrally, what it reads live from SQL Server, Azure SQL and Oracle, why it reads it and how access is controlled.

Last updated: 2026-09-20
Data location Central customer-controlled repository

Historical telemetry, configuration and access data are stored in the configured on-prem administration database. Short-lived SQL Server collection buffers are removed after central synchronization according to configured policy.

Purpose Used for operations and governance

The data supports health checks, reporting, capacity forecasts, incident triage, backup readiness, database-health recommendations, licensing and administration.

AI pages Explainable signals from collected telemetry

Forecast, Incidents, Action Center, Data Quality and Database Health use visible database evidence so DBA teams can review the source behind each recommendation.

Data flowsource, central history and authorized views
Monitored targetsSQL Server, Azure SQL and Oracle expose approved operational metadata, logs and live health signals.
Central admin storageHistorical snapshots are separated by source and include the registered server identity. SQL Server targets keep only a configured local collection buffer.
Web appAuthorized users inspect dashboards, reports and admin pages.
Decision supportForecast and incident scoring stay explainable from visible evidence.

Operational Data Classes

Stored by the appUsers, roles, registered servers, protected connection metadata, license state, alert rules, report schedules, incident cases and application configuration.
Operational telemetryBackup/job history, growth, database metadata, audit/event records, waits, runtime events, permissions and health signals when target permissions allow it.
Not requiredBusiness-table contents are not required for monitoring. Reports show operational repository data, not arbitrary customer application data.
Controlled actionsMaintenance and administration actions require authorized roles. Reader/demo access can inspect permitted evidence without executing protected actions; the admin server's own source is visible only to Admin.

Recommendation Scope

Recommendation text is generated only for operational signals where a DBA decision is useful: failed jobs, backup exposure, telemetry gaps, capacity risk, unhealthy database settings, security findings, blocking, deadlocks and runtime errors. Routine metrics, successful history rows and ordinary audit records are presented as evidence without unnecessary fix instructions.

What dbNexia DEMO Stores

  • User accounts, roles and sign-in metadata needed for authentication and authorization.
  • Registered server metadata, environment labels, server type, connectivity state and collector status.
  • Protected connection metadata required to reach the administration database and registered SQL Server, Azure SQL and Oracle targets.
  • Configuration rows, alert rules, license state, activation metadata and allowed monitored server count.
  • Central historical copies of standard operational tables, tagged and separated by registered source server.
  • Report schedules, incident comments/cause/remediation notes and operational preferences entered by authorized users.

What dbNexia DEMO Reads

  • SQL backup/Agent job and Oracle RMAN/Scheduler history, error, blocking, deadlock, login and connectivity signals.
  • Database file, log, allocation, volume, tempdb/TEMP, tablespace and repository growth telemetry.
  • Database options, index/statistics health, constraints, file-growth settings, security configuration and selected metadata when permissions allow it.
  • Collector health and telemetry gaps that affect confidence in dashboards, reports, Action Center and recommendation pages.
  • Audit or event configuration can include SQL text, login, host, application, object and client-address fields. SQL text may contain values supplied by an application, so collection filters and access rights should follow the organization's data-classification policy.

How The Data Is Used

  • Dashboard: summarizes current health, backup exposure, jobs, workload and collection coverage.
  • Reports: lets authorized users browse collected operational data per server.
  • Forecast: turns historical growth into file, log and volume capacity planning.
  • Incidents: prioritizes runtime, backup, security, blocking and telemetry problems before they become outages.
  • Database Health: explains configuration, index, statistics, integrity and permission findings, and can run controlled fixes for authorized roles.
  • Backup Readiness: filters backup and restore-chain exposure by server, database, recovery model and risk type.

Decision-support Boundaries

The prediction and recommendation views are decision-support tools. They highlight risk, source evidence and recommended DBA action, but they do not replace operational review.

  • No external AI provider is required for the current Forecast, Incidents, Action Center, Data Quality or Database Health recommendations.
  • Predictions depend on telemetry quality, retention, permissions and collector job health.
  • Missing or stale telemetry is treated as a visible operational risk.
  • Automated remediation actions are only available to authorized Admin/Moderator users and should be reviewed before execution.

Access and Protection

  • Authentication is handled through ASP.NET Core Identity.
  • Administration pages are protected with role-based authorization.
  • Reader and demo-style access can view operational evidence but cannot run protected actions. User and License management remain Admin-only.
  • Connection metadata is protected with ASP.NET Core Data Protection. Keys are persisted in the configured administration database and remain bound to the installed application environment.
  • The application should be published behind HTTPS and managed through the customer's normal access process.
  • Exports and scheduled e-mail reports create copies outside the web application; recipients, mail transport and exported files are governed by the customer's own controls.

Retention and Removal

  • Central AuditLog, EventLog, database-size, index-fragmentation, server-metric and table histories use the configured per-table retention settings. Configuration and current inventory snapshots follow their own lifecycle.
  • After a successful central copy, old rows in on-prem SQL Server collection buffers are removed according to the configured local-buffer period. Azure SQL and Oracle do not receive a dbNexia_DB installation.
  • Administrators can remove users, registrations and protected connection metadata. Unregistering a server does not by itself promise erasure of historical central telemetry; purge it through the organization's approved retention/removal process when required.
  • Alert rules, report schedules, incident case notes and server inventory remain in the administration database until changed or removed by authorized users.
  • License information is used only to validate entitlement, expiry and allowed server count.

Plain-language privacy promise

dbNexia DEMO is built to help DBAs operate mixed database estates with clear evidence. The application does not sell customer telemetry, does not require business-table content for its monitoring features, and keeps storage, retention, export and access control with the customer deployment and configured database permissions.