Key principle: for application-consistent snapshots, QUIESCE → SNAPSHOT → RELEASE must be tightly timed and failure-safe so the database is never left quiesced. For crash-consistent snapshots, the snapshot is a single array operation with no database coupling.
Requirements
-
Failure-safe release (application-consistent): END BACKUP / RESUME must execute even if the snapshot fails. Use error traps and cleanup handlers.
-
Timing control (application-consistent): keep the quiesce window to a handful of seconds.
-
Validation: verify all database disk groups (DATA, FRA, REDO) are MOUNTED before snapshotting. Do not enumerate, quiesce, or snapshot the OCR / voting (GRID / CRS / +OCR) disk group.
Operational Best Practices
-
Pre-stage Everpure FlashArray authentication using API tokens or service accounts to avoid interactive prompts during execution.
-
Target a single Protection Group containing all of the database's volumes (and none of the clusterware volumes).
-
Implement comprehensive timestamped logging for audit and troubleshooting.
-
Schedule snapshots during low-activity windows whenever possible.
-
Include change-control identifiers in snapshot names for compliance tracking.
Credential Management
Application-consistent automation needs two identities: an Oracle account that can connect as SYSDBA/SYSBACKUP, and an Everpure FlashArray API token (or username and password). Crash-consistent automation needs only the FlashArray credential. Because the workflow runs unattended, secrets hygiene matters.
-
Centralized vault: store credentials in an organization-approved secrets manager. The automation host authenticates with a machine identity (instance role, service account, AppRole, or similar) and retrieves the secret at runtime.
-
Avoid: hard-coded passwords or API tokens in shell scripts, Ansible playbooks, or YAML configuration files.