Snapshot Consistency Models

Application-Consistent Snapshot (primary, detailed below)

Method: Quiesce the database at the Oracle layer immediately before the snapshot — either with hot backup mode or by suspending the instance — then take the Everpure Protection Group snapshot and release the database as soon as it completes. The Protection Group guarantees write-order consistency across every member volume; the quiesce step adds a clean, Oracle-consistent recovery point on top of that.

• Impact: Brief, controlled pause or backup-mode redo overhead during the snapshot window.

• Recovery: The snapshot reflects a clean, Oracle-consistent point. Restores typically use media recovery with the archived redo generated during the quiesce window; multi-array databases can be captured consistently by quiescing once and taking one Protection Group snapshot per array during the same window.

• Use cases: Production backups and restores, DR protection and testing, multi-array databases, and any site whose standards require an explicit database-layer quiesce before storage snapshots.

  Note: Storage Snapshot Optimization requires licensing Oracle Advanced Compression separately — confirm licensing before enabling this feature.

Crash-Consistent Snapshot (overview below)

Method: Take an Everpure Protection Group snapshot of all database volumes at a single point in time, with no action on the database.

• Impact: Zero database downtime and no I/O pause.

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

• Use cases: Situations where even a brief quiesce cannot be tolerated and Storage Snapshot Optimization licensing is already in place, or lower-stakes reporting and dev/test clones where an OS-level crash-consistent restore is acceptable.

  Recommendation

  For Oracle on ASM, the application-consistent Protection Group snapshot is the recommended default. It produces a clean, Oracle-consistent recovery point and is required when a single Protection Group cannot capture the whole database atomically (for example, a database spread across multiple arrays). Use the crash-consistent workflow only in specific situations — such as when a brief quiesce cannot be accommodated and Oracle Storage Snapshot Optimization licensing is already in place, or for lower-stakes reporting and dev/test clones.

Strategy Summary