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.
Database performance investigation
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 database host
Why it exists
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.
Fifty minutes gathering evidence. Zero minutes fixing.
Nine minutes to root cause, evidence in hand.
Incident bundles
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.
Capabilities
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.
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.
Real-time and snapshot-based analysis, categorized into CPU, I/O, Memory, Lock, Network, and Other — the same six categories on every supported engine, so blocking reads as blocking whether it came from a SQL Server LCK_ wait, a PostgreSQL lock event, or an Oracle enqueue. On SQL Server, the signal-versus-resource breakdown tells you at a glance whether you have CPU pressure or data pressure.
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.
Not a raw DMV dump. Each recommendation is classified as HighConfidence, ReviewRequired, ConflictingDuplicate, or WriteHeavyRisk — so your team works the right ones first.
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.
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.
Beyond SQL Server
The same investigation model, reading each engine’s own native telemetry rather than pretending every database is SQL Server. Each is verified against a live instance. SQL Server remains the engine with production mileage — the three below are new, and we’d rather tell you that than let you find out.
pg_stat_statements extension, which requires a restart to enableevents_waits_* consumers, which MySQL 8 disables by defaultSELECT on the V_$ views (or SELECT_CATALOG_ROLE)Execution plans and missing-index recommendations are genuinely SQL Server-only: they rely on the cached showplan XML and sys.dm_db_missing_index_details, which have no equivalent on the other engines. OroDb hides those panels rather than showing an empty one, and every screen states which engine it is reading and what that engine can and cannot report.
How it works
Add a SQL Server, PostgreSQL, MySQL or Oracle instance with a read-only monitoring login. OroDb builds the right connection string for the engine you pick and tells you the exact grant that engine needs. The connection string is encrypted at rest, or held in Azure Key Vault so the key never touches OroDb’s own database.
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.
Alerts, regressions, plan changes, and newly seen queries land on one correlated timeline. Root cause stops being an archaeology project.
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.
Access control
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.
Full cross-tenant visibility and system configuration.
Manages servers, users, alert rules, and storage for their organization.
Full access to snapshots, query analysis, plans, and the index workflow.
Health dashboard in plain English. No SQL, no plans, no raw data.
Honest fit
We’d rather you know upfront. OroDb is a focused database investigation tool — deepest on SQL Server, newly in preview on PostgreSQL, MySQL and Oracle — not a full APM platform.
Security & compatibility
OroDb reads from standard DMVs available since SQL Server 2014, and from each other engine’s own catalog views. No extended events, no trace flags, no schema changes on the databases it watches — and on Oracle, nothing that requires a Diagnostics Pack licence.
VIEW SERVER STATE; PostgreSQL pg_monitor; MySQL SELECT on performance_schema plus PROCESS; Oracle SELECT on the V_$ views. It never writes to a monitored database — ever.Supported platforms
* Azure SQL Database: the server-configuration section is omitted from incident bundles, as sys.configurations is not exposed there.
Solid outline = production mileage. Dashed = preview: verified against a live instance of that engine, with the per-engine limits listed above.
oro · Spanish for gold — what your telemetry becomes
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