Oracle Data Guard & RAC triage — Field Kit

Field Kit / Oracle

Scope: Oracle 11g–21c · Data Guard (physical standby) & RAC · Linux/Unix & Windows Run this first — never assume: SELECT banner FROM v$version; and SELECT database_role, open_mode, platform_name FROM v$database; — release, role and OS change which fix applies.

Fuzzy: typos are fine. ORA- numbers match error codes. The chips below browse by category; the filter above narrows to your environment.

Paste an error message / alert-log snippet

Paste an ORA- error or a chunk of the alert log — it pulls the codes and classifies them below. Nothing leaves the browser.

Triage tree

Symptom → cause → numbered fix. Every outcome names the dependencies to check and when to escalate. Jump into any area, or search above for a specific code.

Now — first-responder scripts

Copy-paste diagnostics for "what's happening right now." Comments say where to run each and what healthy looks like. All read-only unless flagged.

Data Guard health, explained

A standby is “healthy” only when four things are true at once: redo is shipping (transport), redo is applying, there is no gap, and the config can actually change roles on demand. Each row is one signal — where to read it, what good looks like, and the red flag.

Signal	Where (view)	Healthy	Red flag
Role & mode	`v$database`	Primary READ WRITE · standby MOUNTED / READ ONLY	Standby READ WRITE → split-brain risk
Redo transport	`v$archive_dest_status`	STATUS = VALID, no error	ERROR / DEFERRED = redo not shipping (16778/16191)
Redo apply	`v$managed_standby`	MRP0 = APPLYING_LOG	No MRP row = apply stopped (16766)
Apply / transport lag	`v$dataguard_stats`	near zero	Growing = falling behind; breaks FSFO (16853)
Archive gap	`v$archive_gap`	no rows	Rows = missing sequences (16724)
Standby redo logs	`v$standby_log`	present, sized like online redo	None = no real-time apply; SYNC falls to ARCH (16789)
Protection & switchover	`v$database`	mode as designed; TO STANDBY / TO PRIMARY	Other switchover_status = not safe to switch roles
Broker view	`DGMGRL SHOW CONFIGURATION`	SUCCESS	WARNING / ERROR (16809 / 16810)

Protection modes — the RPO dial:

Maximum Performance (ASYNC) — no commit impact, a small data-loss window. The default.
Maximum Availability (SYNC / FASTSYNC) — zero data loss while the standby is reachable; auto-falls back to ASYNC if it isn’t.
Maximum Protection (SYNC) — zero data loss, guaranteed: the primary will stall commits rather than lose its last standby.

Versions & platform — don’t assume: covers 11g–21c. The breakpoints that bite: 12c brought multitenant (CDB/PDB) and RedoRoutes; 12.2 deprecated FAL_CLIENT and added FASTSYNC; 19c is the long-term release most shops run. Paths differ by OS — the password file, archive dest and clusterware logs are in different places on Linux/Unix vs Windows, and ASM vs filesystem changes the reclaim path. On RDS Oracle you manage it through rdsadmin, not directly. Each error card flags its own version/OS trap.

Write up the ticket

Once it’s resolved, assemble a paste-ready summary. Any triage outcome above has an Add to ticket button that fills this in — edit and copy. Nothing is stored or sent.

Target — DB / DG config / host Symptom / error Root cause Actions taken (one per line) Follow-ups / DR restored?

Field Kit — offline Oracle Data Guard & RAC incident triage · a ReliabilityOps tool by Grand Canyon Computers. Decision-tree triage built from vetted references for Oracle 12c–19c/21c; confirm against your version and your site's runbook before acting on production. Every query here is read-only. Nothing on this page calls the network; your inputs never leave the browser.