ORA-07445 in the alert log means an Oracle server process received a fatal operating system signal and dumped core. A foreground or background process crashed inside Oracle kernel code, PMON cleaned up the session, and Oracle wrote an incident to the Automatic Diagnostic Repository (ADR). Unlike a normal ORA- error returned to a client, ORA-07445 is the kernel telling you a process died underneath the database.

This error is always critical. ORA-07445 in a production instance warrants immediate investigation regardless of frequency, and the standard escalation is to capture the trace and engage Oracle Support. It is not a tuning signal, not a capacity warning, and not something you can ignore because the database appears to keep running. A single ORA-07445 can be an isolated bug hit; a cluster of them can mean corruption, a bad patch, or failing hardware.

What follows is how to distinguish it from ORA-00600, capture the diagnostic material Oracle Support will ask for, and triage common root causes without destroying evidence.

What this means

ORA-07445 is raised when an Oracle process hits an unhandled operating system exception. The kernel delivered a fatal signal (typically SIGSEGV, SIGBUS, SIGFPE, or SIGILL) to an Oracle-owned process, and Oracle’s signal handler caught it, wrote a core file and a trace file, logged the event, and terminated the process. PMON then reclaims the session’s resources.

The alert log entry carries six bracketed arguments. The canonical form is:

ORA-07445: exception encountered: PC=[...] [function+offset] [signal] [address] [code] [flags]

The first bracketed argument (the Oracle function name and byte offset) is the single most important piece of information you will collect. Oracle Support’s ORA-07445 lookup tool indexes on that function+offset value, and without it the tool cannot match your crash to a known bug.

ORA-07445 vs ORA-00600. These two errors are related but distinct, and the distinction drives triage:

ErrorWhat happenedWho raised it
ORA-07445Unhandled OS exception; a signal arrived from the kernel and Oracle did not anticipate itThe operating system
ORA-00600Internal assertion; Oracle code detected an inconsistent state and raised the error itselfOracle kernel

Both are always critical, both require Oracle Support engagement, and both write ADR incidents. ORA-07445 implies a process crash (the OS killed it); ORA-00600 implies an internal sanity check fired. When a customer or colleague asks “is this serious?”, the answer is the same for both: yes.

flowchart TD
  A[ORA-07445 in alert log] --> B[Capture all 6 bracketed args]
  B --> C[Pull trace + core from ADR via adrci]
  C --> D{Corruption signals?}
  D -- ORA-01578 or V$DATABASE_BLOCK_CORRUPTION --> E[RMAN validate, block recovery]
  D -- None --> F[Run MOS ORA-7445 lookup on function+offset]
  F --> G{Known fix?}
  G -- Yes --> H[Apply patch or documented workaround]
  G -- No --> I[Package AHF SRDC, open SR]

Common causes

CauseWhat it looks likeFirst thing to check
Oracle bugRecurring crashes with the same function+offset; often after a patch or upgradeThe first bracketed argument against the MOS ORA-7445 lookup tool
Block or data corruptionORA-07445 paired with ORA-01578 / ORA-01110, or a specific object/SQL always triggers itV$DATABASE_BLOCK_CORRUPTION and an RMAN VALIDATE
Severe misconfigurationCrashes under a specific workload path; bad parameter or unsupported combinationRecent parameter changes, OPTIMIZER_FEATURES_ENABLE, hidden parameters
OS or kernel incompatibilitySpate of ORA-07445 after a kernel or OS upgrade, or in a containerized deploymentdmesg, OS release, kernel version, hugepage configuration
Hardware memory faultRandom, non-reproducible crashes across many processes and SQLEDAC / mcelog, DIMM error counters

Quick checks

Run these before you do anything destructive. All are read-only.

# Tail the alert log for the ORA-07445 entry and its arguments
adrci exec="show alert -tail 200" | grep -A3 -B1 "ORA-07445"

-- Recent critical incidents from ADR (12c+)
SELECT incident_id, problem_key, create_time, status
FROM V$DIAG_INCIDENT
WHERE problem_key LIKE '%ora%7445%'
ORDER BY create_time DESC;

-- XML alert log, last 24h, filtered to critical errors (12c+)
SELECT originating_timestamp, message_text
FROM V$DIAG_ALERT_EXT
WHERE originating_timestamp > SYSDATE - 1
  AND REGEXP_LIKE(message_text, 'ORA-07445|ORA-00600|ORA-01578|ORA-01110')
ORDER BY originating_timestamp DESC;

-- Confirm the instance is still OPEN/ACTIVE after the crash
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS, ACTIVE_STATE
FROM V$INSTANCE;

-- Check for any block corruption (empty result is good)
SELECT FILE#, BLOCK#, BLOCKS, CORRUPTION_TYPE
FROM V$DATABASE_BLOCK_CORRUPTION;

# OS-level evidence: OOM kills, hardware faults, kernel messages
dmesg -T | grep -iE "out of memory|oom|sigsegv|sigbus|mce|hardware error"

The alert log path on disk is $ORACLE_BASE/diag/rdbms/<db_unique_name>/<instance_name>/trace/alert_<instance>.log. adrci is preferred over raw tail because it resolves the ADR home automatically.

How to diagnose it

  1. Preserve evidence first. Before restarting, patching, or flushing anything, copy the alert log, the trace file, and the core file out of ADR. Oracle Support cannot diagnose a crash you overwrote.
  2. Extract the function+offset argument. From the ORA-07445 line, pull the first bracketed value (for example kggchk()+52). This is your lookup key.
  3. Open the trace file. Use adrci to inspect the incident (show incident -mode detail -p "incident_id=<id>") or navigate to the incident directory under $ORACLE_BASE/diag/rdbms/.../<instance>/incident/. The trace contains the call stack, the SQL text (if any), and the register dump.
  4. Identify the triggering SQL and object. The trace usually records the SQL being executed and the object accessed. If the same statement or segment recurs across incidents, that is a strong lead.
  5. Rule out corruption. Query V$DATABASE_BLOCK_CORRUPTION (populated by prior RMAN, ANALYZE, or DBVerify checks) and schedule an RMAN BACKUP VALIDATE CHECK LOGICAL DATABASE if the crash pattern points at a specific datafile.
  6. Rule out OS and hardware. Check dmesg for OOM kills, EDAC/MCE errors, and storage faults. A kernel or glibc upgrade immediately before the first ORA-07445 is a prime suspect.
  7. Run the MOS lookup. In My Oracle Support, use the ORA-600/ORA-7445/ORA-700 Error Look-up Tool (referenced in MOS Note 7445.1). Paste the function+offset and the full argument list. The tool returns known bugs, affected versions, and any available one-off patch.
  8. Package the incident for support. With Autonomous Health Framework installed, run as the Oracle software owner:
# Collect the SRDC package Oracle Support expects for ORA-07445
tfactl diagcollect -srdc ORA-07445

Upload the resulting zip to the MOS lookup tool or attach it to a new Service Request. If AHF is not installed, use the adrci Incident Packaging Service (IPS) to build the package manually.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
Alert log ORA-07445 patternThe universal correlation anchor; the arguments are the diagnosisAny occurrence in production; recurring identical function+offset is a bug
V$DIAG_INCIDENT ORA-07445 count over timeTrend reveals regressions after patches or hardware degradationCount rising week over week, or a new function+offset appearing
V$DATABASE_BLOCK_CORRUPTIONCorruption is a frequent ORA-07445 co-conspiratorAny non-zero row
V$INSTANCE statusA crash of a background process (DBWn, LGWR, PMON) can take the instance downSTATUS leaves OPEN, instance restarts
OS memory and OOM (dmesg)Memory corruption and OOM kills masquerade as ORA-07445OOM killer entries targeting Oracle PIDs, EDAC/MCE errors
log file sync, free buffer waitsNot causes, but they tell you whether the crash destabilized the write pathLatency spikes coincident with the crash

Fixes

Treat the fix path as cause-specific. Do not restart the instance as a first response unless a critical background process died and the instance is down. Restarting destroys in-memory state and, if the core was not yet written, can lose the crash artifact.

Oracle bug

If the MOS lookup returns a known bug, apply the documented fix: a one-off patch, a patch set update, or an upgrade. Where a workaround is published (for example, disabling an optimizer feature or setting an underscore parameter), treat it as a stopgap and schedule the real patch. Document the workaround and the reason in your runbook so it is not mistaken for a permanent setting.

Block or data corruption

If V$DATABASE_BLOCK_CORRUPTION is non-zero or the trace points at a specific block, use Block Media Recovery (BMR) via RMAN to restore individual corrupt blocks from backup without taking the datafile offline. If corruption is widespread or recurs after recovery, suspect the storage layer and involve your storage team. Distinguish physical corruption from NOLOGGING-induced blocks (ORA-01578 with ORA-26040), which are not real corruption and are resolved by reloading the data, not by block recovery.

Severe misconfiguration

Review recent parameter changes, especially hidden (underscore) parameters, OPTIMIZER_FEATURES_ENABLE changes after an upgrade, and any ALTER SYSTEM issued around the time of the first crash. If a new workload path exercises the crashing code, the fastest mitigation is often to disable that path (for example, an optimizer feature) until a patch lands.

OS or kernel incompatibility

ORA-07445 storms immediately after a kernel upgrade, a glibc update, or a move into containers are a recognized pattern. Verify hugepages are configured for the SGA, confirm the Oracle version is certified against the OS and kernel, and check that container resource limits and ulimit settings allow core dumps of the expected size. If a kernel rollback resolves the crashes, file an SR and keep the rollback until a certified combination is available.

Hardware memory fault

If crashes are random across processes and SQL and mcelog or EDAC report correctable or uncorrectable memory errors, treat the DIMM as the prime suspect. Oracle does not fix bad RAM; you replace it.

Prevention

  • Stay patched. Most ORA-07445 incidents match a known bug with a known fix. Running a supported, current patch level is the highest-leverage preventive control you have.
  • Enable block integrity checks. DB_BLOCK_CHECKING = FULL (or MEDIUM) and DB_BLOCK_CHECKSUM = FULL catch corruption before it propagates. Both add modest CPU overhead and are recommended for production.
  • Schedule RMAN VALIDATE. A recurring BACKUP VALIDATE CHECK LOGICAL DATABASE populates V$DATABASE_BLOCK_CORRUPTION so you find bad blocks before a server process does.
  • Validate upgrades in a non-production replica. Plan regressions and ORA-07445 spikes frequently appear after a version move. Run real workload replay before promoting.
  • Confirm core dump settings. Ensure shadow_core_dump and OS ulimit -c allow a usable core file. A truncated or missing core weakens every SR.

How Netdata helps

  • Alert log ingestion surfaces ORA-07445 (and ORA-00600, ORA-01578) as it is written, so a crash is visible within seconds rather than at the next manual adrci check.
  • Per-second instance status from V$INSTANCE shows immediately whether a background-process crash took the instance down or whether the database is still OPEN but degraded.
  • ADR incident rate trending lets you see a rising ORA-07445 cadence after a patch or kernel change before it becomes an outage.
  • Correlation with OS signals (OOM kills, memory errors, CPU saturation, disk latency) helps you decide quickly whether a crash is an Oracle bug or a hardware/OS problem.
  • Block corruption visibility alongside the alert log ties an ORA-07445 back to a specific datafile when corruption is the cause.

Netdata’s Oracle Database monitoring brings these signals together with per-second metrics and ML anomaly detection.