A single-file triage kit for SQL Server, PostgreSQL/RDS and Oracle Data Guard. No install, no network, never touches your database — it turns read-only query output into decisions.
So the kit is one rule: get vetted, decision-grade information in front of the responder at each stage — fast, offline, and safe to run during an incident.
Every branch surfaces the vetted facts you need, then names the dependencies to check and when to escalate.
No backend, no CDN, no install. Runs from a file share, a USB stick, or an email attachment — the same everywhere.
You run read-only queries yourself and paste the output in. It's a smart document, not an agent — so there's nothing to security-review.
Failover audit, error triage, query library, AG reference, incident log.
Waits, errors, what's-happening-now during an incident.
The teaching layer — how Always On actually works.
The same field-kit approach for the Postgres world.
Redo transport, apply lag, gaps, switchover/failover, clusterware.
App-layer triage: errors, latency, timeouts, bad deploys — the signal to check and the likely cause.
Per domain: what to measure, what to look for, how to read it, and Dynatrace setup tips.
Run the outage: phase flow, what to ask each domain, comms, timeline → postmortem. Not just databases.
Collection is scripts you run yourself; the thinking happens in the browser. Every query is read-only and commented with where to run it and what healthy looks like.
-- Oracle: apply & transport lag (run on the standby) SELECT name, value, unit, time_computed FROM v$dataguard_stats WHERE name IN ('apply lag','transport lag'); -- SQL Server: is the AG synchronizing / healthy? SELECT ag.name, drs.synchronization_state_desc, drs.synchronization_health_desc FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_groups ag ON ag.group_id = drs.group_id;
Drop in an ORA- code or a SQL error (or a whole chunk of the log). The kit classifies it, tells you what it means, and gives the first move — no tribal knowledge required.
Managed recovery stopped applying redo — the standby drifts behind and isn't a valid failover target until apply restarts.
First move: restart apply — broker EDIT DATABASE '<stby>' SET STATE='APPLY-ON'.
The STATE in the errorlog tells you why. Post-DR, states 11/12/38 usually mean the login or its default DB didn't come over.
First move: read the state from the errorlog, then run the Detect login-transfer instead of fixing one by one.
At 2am you don't remember what "healthy" even looks like. So the tool just tells you, in plain words: here's the thing to check, here's normal, here's the alarm. No digging.
| Ask yourself | Good | Trouble |
|---|---|---|
| Who's the primary? | One clear primary | Two think they're primary → split-brain |
| Is the standby keeping up? | Lag near zero | Lag growing → it's falling behind |
| Is data reaching the standby? | Synced / shipping | Stopped → your DR is cold, not hot |
| Safe to fail over? | Status says ready | Anything else → don't switch yet |
The tool carries the exact view names and commands behind each of these — this is just the plain-English version so you always know what you're looking at.
Work the tree, hit Add to ticket on the outcome, and the triage becomes a paste-ready incident writeup — symptom, root cause, actions taken. The SQL tool's log exports the same way.
"A check that's missing, a query that's off, a topic you want covered — it goes straight to me." Every tool carries this button, so corrections happen where the knowledge lives.
Add a domain. Extend a branch. Your domain, your triage logic, vetted by you. That's how it goes from one person's kit to the team's resilience layer.
One consistent pattern across every domain — SQL Server, PostgreSQL, Oracle, incidents — so the whole team works the same way, on practices that are already proven instead of reinventing the fix each time. That consistency is the point: shared muscle memory for the moment it counts.