Incident bundles Capabilities How it works Security Open the app Contact

SQL Server performance investigation

Monitoring tells you it’s slow.
OroDb tells you why.

OroDb fingerprints every query, watches each one against its own rolling baseline, and correlates plan changes, wait stats, and alerts on a single timeline — then packages the evidence into a one-click incident bundle when it’s time to escalate.

Read-only access  ·  no agents  ·  nothing installs on your SQL Server host

fp/a3f2c1b8  ·  SELECT … FROM Orders WHERE CustomerId = @P  ·  CPU ms per execution Regression · +67% vs 7-day baseline
240 ms 180 ms 120 ms 60 ms 7-day rolling baseline · 124 ms plan hash changed · 9e4a → 7c8f 207 ms
Mar 18Mar 19Mar 20Mar 21Mar 22 · 13:10 UTC
SHA-256 query fingerprints sys.dm_os_wait_stats Plan shape hashing VIEW SERVER STATE only SQL Server 2014 – 2022 · Azure SQL

Why it exists

Built for the page that arrives at 2:47 a.m.

Every DBA knows the sequence. The application is slow, the evidence is scattered across six DMV queries, and the clock is running. OroDb collapses that sequence into minutes.

Without OroDb
2:47Paged. “Orders page is timing out.” No history, no context.
2:55Query sys.dm_os_wait_stats by hand. Numbers, but no baseline to compare against.
3:10Hunt for the offending query. Pull plans, guess whether they changed. Screenshot everything.
3:32Assemble wait stats, plan XMLs, config, and alert history from six places into a support ticket.
3:40Escalate — and hope you captured the right window.

Fifty minutes gathering evidence. Zero minutes fixing.

With OroDb
2:47Alerted by OroDb — CPU pressure rule fired. Signal wait 34.2%, above your 25% threshold.
2:49Open the timeline. One query regressed +67% against its own baseline, and its plan hash changed at 13:10.
2:52Review the plan in the browser. Cause identified — and the fix has an index recommendation already classified.
2:54Export the incident bundle: wait stats, plans, config, alert history, and a plain-English summary in one ZIP.
2:56Escalate with the complete picture — or fix it yourself and watch the baseline recover.

Nine minutes to root cause, evidence in hand.

Incident bundles

One click. Everything support needs.

When things are on fire, nobody has time to pull wait stats, plan XMLs, alert history, and server configuration from six different places. OroDb packages all of it — plus a plain-English narrative for the non-DBAs on the thread — into a single, vendor-escalation-ready ZIP.

What used to take forty-five minutes to assemble for a vendor ticket is now one button. Every bundle: manifest, summary, evidence, and recommendations
incident_bundle_prod-sql-01_20260322.zip 11 files · 197 kb
README.txtManifest and support instructions2 kb
00_SUMMARY.txtPlain-English narrative, written for non-DBAs4 kb
01_wait_stats.csvTop 30 wait types with all metrics8 kb
02_active_waits.csvSessions waiting at capture time3 kb
03_top_queries.txtTop 20 queries by resource usage12 kb
04_plans/query_01.htmlExecution plan — opens in any browser84 kb
04_plans/query_02.htmlExecution plan — opens in any browser71 kb
05_index_recommendations.sqlCREATE INDEX scripts — review before running6 kb
06_alert_history.csvRecent alerts for this server2 kb
07_server_config.txtsys.configurations snapshot2 kb
08_regressions.txtQueries above baseline, with details3 kb

Capabilities

Every signal a DBA reads, in one place

From raw wait types to plain-English business impact — each capability is built on the DMVs you already trust, with a structured workflow to act on what they say.

sys.dm_exec_query_stats + SHA-256

Query fingerprinting

Literals stripped, whitespace normalized, structure hashed. Two parameterized queries doing the same logical work share one fingerprint — which is what makes honest trend tracking possible across captures.

sys.dm_os_wait_stats

Wait stats engine

Real-time and snapshot-based analysis, categorized into CPU, IO, Memory, Lock, and Other. The signal-versus-resource breakdown tells you at a glance whether you have CPU pressure or data pressure.

Plan shape hash comparison

Plan regression detection

OroDb hashes the structural shape of execution plans across snapshots. When a plan changes and performance drops at the same time, it’s flagged — before your users notice.

sys.dm_db_missing_index_details

Classified index recommendations

Not a raw DMV dump. Each recommendation is classified as HighConfidence, ReviewRequired, ConflictingDuplicate, or WriteHeavyRisk — so your team works the right ones first.

Per-server rule evaluation

Configurable alerts

Define thresholds per server: signal wait percentage, IO wait share, specific wait types. Rules are evaluated on every snapshot with a 30-minute deduplication window; critical alerts send email automatically.

Correlated event stream

Incident timeline

Alerts, regressions, plan changes, and new fingerprints on one chronological view. Zoom from 1 to 30 days to see exactly what changed and when — the post-mortem view, available before the post-mortem.

How it works

Connected in minutes. Learning from the first snapshot.

i.

Connect a server

Add any SQL Server instance with a read-only DMV login. The connection string is encrypted at rest, or held in Azure Key Vault so the key never touches OroDb’s own database.

ii.

Capture snapshots

On demand, or on a schedule you define with a cron expression. Each snapshot records wait stats and the top 20 queries, and writes a new data point to every fingerprint’s trend.

iii.

Read the timeline

Alerts, regressions, plan changes, and newly seen queries land on one correlated timeline. Root cause stops being an archaeology project.

iv.

Act, and watch it recover

Approve and assign index recommendations, export incident bundles, and watch the baseline recalibrate. Regression flags clear on their own as the trend returns to normal.

snapshot captureprod-sql-01
$orodb snapshot --server prod-sql-01
Connecting to prod-sql-01:1433…
✓ Connection established (38 ms)
Capturing wait stats (sys.dm_os_wait_stats)…
✓ 312 wait types captured
⚠ Signal wait 34.2% — above 25% threshold
Fingerprinting top 20 queries…
✗ Regression: fp/a3f2c1b8 — CpuMs +67% vs baseline
⚠ Plan hash changed: 9e4a → 7c8f
⚠ AlertRule fired: CpuPressure · SignalPercent 34.2 > 25
✓ Snapshot saved (snap/d9147cbe) — 1.4 s

Access control

The right view for every person on the thread

OroDb adapts to the reader. DBAs get execution plans and DMV data; executives get health status in plain English — no SQL required, and no way to touch what they shouldn’t.

SuperAdmin

Platform admin

Full cross-tenant visibility and system configuration.

  • All tenant access
  • User management
  • Audit log access
  • System configuration
TenantAdmin

Tenant admin

Manages servers, users, alert rules, and storage for their organization.

  • Server management
  • Alert rule creation
  • User invitations
  • Report configuration
DbaAnalyst

DBA analyst

Full access to snapshots, query analysis, plans, and the index workflow.

  • Snapshot capture
  • Execution plan viewer
  • Fingerprint trends
  • Index rec approval
ReadOnly

Executive view

Health dashboard in plain English. No SQL, no plans, no raw data.

  • Health overview
  • Business impact framing
  • Issue summaries
  • Read-only, no actions

Honest fit

Who this is for — and who it isn’t

We’d rather you know upfront. OroDb is a focused investigation tool for SQL Server, not a full APM platform.

This is for you if…

  • You manage 1–50 SQL Server instances and want performance history that actually means something
  • You get paged about slow queries and lose time gathering evidence before you can act
  • You want a structured approval workflow for index changes — not ad-hoc scripts
  • You escalate to Microsoft support and need a clean, complete data package
  • You want your manager to understand database health without reading DMVs
  • You’re on SQL Server 2014 or newer, on-prem, VM, or Azure SQL

This isn’t for you if…

  • You need full APM across mixed stacks — Node, Python, Java — a general-purpose APM suite fits better
  • You’re primarily on PostgreSQL or MySQL — not supported yet
  • You need sub-second metric streaming — snapshots are periodic, not continuous
  • You want indexes applied automatically with no human review in the loop
  • You need RDS SQL Server today — it’s on the roadmap

Security & compatibility

Built to be trusted with production

OroDb reads from standard DMVs available since SQL Server 2014. No extended events, no trace flags, no schema changes on the databases it watches.

AES-256 encryption at restEvery connection string is encrypted. Azure Key Vault integration is available so the key never touches the OroDb database.
Read-only, by designOroDb needs only VIEW SERVER STATE. It never writes to a monitored database — ever.
No agent, no schema changesDeployed as an ASP.NET Core application. Nothing installs on your SQL Server host; your monitored databases are untouched.
Multi-tenant with full isolationEach customer’s data is isolated by tenant. Users see only the servers and data that belong to their organization.
Microsoft and Google SSOSign in with Microsoft Entra ID or Google OAuth. Local accounts with one-time-code email verification are also supported.

Supported platforms

SQL Server 2014 SQL Server 2016 SQL Server 2017 SQL Server 2019 SQL Server 2022 Azure SQL Database * Azure SQL Managed Instance RDS SQL Server · roadmap

* Azure SQL Database: the server-configuration section is omitted from incident bundles, as sys.configurations is not exposed there.

oro · Spanish for gold — what your telemetry becomes

See what your server has been trying to tell you.

Connect a read-only login and watch your first query fingerprints appear in about a minute. Or walk through the live demo first — it’s pre-loaded with real trends, a regression, and an incident bundle.

Read-only access  ·  no agents  ·  no schema changes on monitored databases