Crash-Consistent Snapshot Workflow (Overview)

Oracle
Audience
Public
Technology Integrations
Oracle
Source Type
Documentation

This section is an overview, not a step-by-step runbook. Crash-consistent snapshots reuse the same Protection Group mechanics as Steps 1–2 of the application-consistent workflow above — the only difference is that no Oracle-layer quiesce is performed. The Protection Group requirements and the OCR / voting exclusion are identical between both workflows. A single crash-consistent Protection Group snapshot also cannot capture a multi-array database atomically; use the application-consistent workflow for that case.

Concept

Take the Protection Group snapshot directly, with no action at the Oracle layer. Because there is no quiesce, this workflow does not require SYSDBA/SYSBACKUP access — Everpure FlashArray credentials alone are sufficient.

Key points

  • Zero database impact: no pause, and no backup-mode redo overhead.

  • Recovery: Oracle performs crash recovery on startup after a restore. With Oracle Storage Snapshot Optimization (MOS Doc ID 604683.1) licensed, the snapshot can instead be used to recover to a point in time without placing the database in backup mode.

  • Exclude OCR / voting. As with the application-consistent workflow, the GRID / CRS / +OCR disk group is never included in the Protection Group and is never quiesced.

Note: When crash-consistent is appropriate. Use the crash-consistent workflow only in specific situations: production windows where even a brief quiesce cannot be scheduled and Oracle Storage Snapshot Optimization licensing is already in place, or lower-stakes reporting and dev/test clones where a plain crash-recovery restore is acceptable. For production DR protection and for multi-array databases, use the application-consistent workflow above.