Application-Consistent Snapshot Workflow (Detailed)

Identify the database ASM disk groups and map each ASM disk to its FlashArray volume.

Create or verify the Everpure Protection Group containing only those database volumes.

Quiesce the database at the Oracle layer (hot backup mode or instance suspend).

Take the Protection Group snapshot while the database is quiesced.

Release the database immediately (end backup mode or resume).

Record the snapshot metadata.

Validate database and snapshot status.

Identify disk groups and map ASM disks to FlashArray volumes

This is the most error-prone part of building the Protection Group, so it is broken into sub-steps. The goal is to turn each ASM disk into the exact FlashArray volume name you will add to the Protection Group. The link between the two is the device's storage identifier: a SCSI WWID (iSCSI/FC) or an NVMe NGUID (NVMe-oF), both of which embed the volume's serial as known to the array.

1. List the disk groups and their ASM disks

   Capture the OS device path (the PATH column) for every disk in each database disk group:

   # List all disk groups with state and redundancy
   asmcmd lsdg
    
   # List the disks (and their OS paths) backing a given database disk group
   asmcmd lsdsk -G DATA
    
   # More detail, including the kernel device, if needed
   asmcmd lsdsk -k -G DATA
   

   Alternatively, as of Oracle 19c you can query the views directly from the database instance. The v$asm_diskgroup and v$asm_disk views contain the same disk-group-to-OS-path mapping, so you can retrieve it with SQL against the database instance itself — no separate ASM instance login or asmcmd access required:

   -- From the database instance (not +ASM)
   COLUMN diskgroup  FORMAT A15
   COLUMN path       FORMAT A40
   COLUMN os_mb      FORMAT 999,999,999.99
   
   SELECT g.name AS diskgroup, d.path, d.os_mb
   FROM   v$asm_diskgroup g
   JOIN   v$asm_disk d ON d.group_number = g.group_number
   ORDER BY d.path;
   
   --Optionally add:
   WHERE  g.name = 'DATA'
   
   

   The PATH shown depends on how disks are presented. Common forms:

   • multipath aliases such as /dev/mapper/dg_rac_data01

   • ASMLib paths such as /dev/oracleasm/disks/DATA01

   • Raw multipath devices such as /dev/dm-18.

   For NVMe-oF, paths are NVMe namespaces or udev aliases over them, such as /dev/nvmeasm/ASM_DATA01 or /dev/nvme1n1. You will resolve whichever you have to a volume identifier.

2. Determine your transport: SCSI (WWID) or NVMe-oF (NGUID)

   The correlation method depends on how the volumes are presented. Check the device path from Step 1a: a nvme device or a path under /dev/nvme* (including udev aliases such as /dev/nvmeasm/ASM_DATA01) means NVMe-oF use Path B. A SCSI device (iSCSI/FC) presented through multipath means Path A. Confirm quickly:

   # Resolve the ASM path to the real device first
   readlink -f /dev/nvmeasm/ASM_DATA01     # -> /dev/nvme1n1  => NVMe-oF (Path B)
   readlink -f /dev/mapper/dg_rac_data01   # -> /dev/dm-18    => SCSI multipath (Path A)
    
   # Or list what's present
   nvme list           # populated => NVMe-oF is in use
   multipath -ll       # populated => SCSI multipath is in use
   
   

   Path A — SCSI (iSCSI / Fibre Channel): WWID

   Get the WWID for the device behind each ASM disk, then convert it to a volume serial.

   # Show the WWID and underlying paths
   multipath -ll
   multipath -ll /dev/mapper/dg_rac_data01
    
   # Or query the WWID directly from an underlying block device
   /lib/udev/scsi_id -g -u -d /dev/sdc      # -> 3624a9370<serial>
    
   # ASMLib: map the ASM disk to its block device first
   oracleasm querydisk -d DATA01            # major/minor -> underlying /dev/sdX
   

   A FlashArray SCSI WWID has the form 3624a9370 + <volume serial>. The 3624a9370 portion is the constant vendor prefix; the array omits it in its displays. Strip the prefix and the remainder is the serial:

   # Example WWID from multipath -ll:
   #   3624a937050c939582b0f46c00031e3f4
   #   constant prefix: 3624a9370
   #   volume serial  : 50C939582B0F46C00031E3F4   (uppercase to match the array)
    
   WWID="3624a937050c939582b0f46c00031e3f4"
   SERIAL=$(echo "${WWID#3624a9370}" | tr "a-f" "A-F")
   echo "$SERIAL"   # 50C939582B0F46C00031E3F4
   
   

   Path B — NVMe-oF (NVMe/TCP, NVMe/FC, NVMe/RoCE): NGUID

   NVMe devices do not use a WWID or the 3624a9370 prefix. They expose an NGUID. First resolve each ASM disk to its namespace device and read its NGUID:

   # Resolve each ASM udev symlink to the real NVMe namespace device:
   for d in /dev/nvmeasm/ASM_DATA0*; do
       printf "%s -> %s\n" "$d" "$(readlink -f "$d")"
   done
   #   /dev/nvmeasm/ASM_DATA01 -> /dev/nvme1n1
    
   # List namespaces with NGUID / serial / model
   nvme list -o json
    
   # Read the NGUID for one namespace
   nvme id-ns /dev/nvme1n1 -o json | grep -i nguid
   cat /sys/block/nvme1n1/wwid              # shows eui.<nguid> for NVMe
   

   For a FlashArray, the NGUID is structured in three parts: the first 8 bytes are a leading 00 followed by the first 7 bytes of the FlashArray ID; the next 3 bytes are Pure's company ID (24a937); and the last 5 bytes are the unique identifier of the individual volume. That trailing segment matches the tail of the volume serial on the array.

   # Example NGUID layout:
   #   00<7-byte FlashArray ID>  24a937  <5-byte volume id>
   #   |__ 8 bytes ___________|  |_3 b_|  |__ 5 bytes ____|
   #
   # Confirm the two array-side values:
   purearray list                     # FlashArray ID (matches the bytes after the leading 00)
   purevol list --human-readable      # Name + Serial for every volume
   purevol list ASM_DATA01            # confirm one volume's serial
    
   # Match the trailing volume id (last 5 bytes / 10 hex chars) to the volume serial
   

3. Match to the volume name and record the mapping

   Whichever path you used, the result is a serial (or volume-id segment) that identifies one FlashArray volume. Find it in the volume list; the Name column is what you add to the Protection Group:

   # SCSI: match the full serial
   purevol list | grep -i 50C939582B0F46C00031E3F4
    
   # NVMe: match the trailing volume-id segment of the NGUID
   purevol list | grep -i <last-5-bytes-of-nguid>
   #   Name         Size  Source  Created            Serial
   #   ASM_DATA01   200G  -       2026-03-16 ...      ...50C939582B0F46C00031E3F4
   

   Do not assume names line up. ASM disk names (DATA01_0000) and udev aliases (ASM_DATA01) are assigned locally and will not necessarily match the array volume order. Verify every disk through its WWID or NGUID. Repeat 1b–1d for every ASM disk in every database disk group, and record disk group, ASM disk, OS path, WWID/NGUID, serial, and volume name together so the mapping is auditable.

Add the FlashArray volume names you mapped in Step 1 to one Protection Group. If it already exists, verify membership rather than recreating it. Commands below use the Everpure (Purity) CLI; the same actions are available via the REST API and SDKs.

# Create the Protection Group (one-time)
purepgroup create pg-prod-ORCL-rac
 
# Add the database volume names resolved in Step 1 (DATA, FRA, REDO)
purevol add vol-prod-ORCL-data01 vol-prod-ORCL-fra01 vol-prod-ORCL-redo01 \
    --pgroup pg-prod-ORCL-rac
 
# Verify membership matches your Step 1 mapping before the maintenance window
purepgroup list pg-prod-ORCL-rac

Quiesce the database

Quiesce the database at the Oracle layer immediately before the snapshot, using either hot backup mode or instance suspend, then release it as soon as the snapshot completes. The quiesce is performed against the database instance, not against ASM — there is no disk-group freeze. Run it from one instance; it applies to the whole database.

Method A — Hot backup mode

Place the whole database in backup mode, snapshot, then end backup mode. Restores use media recovery with the archived redo generated during the window.

-- As SYSDBA / SYSBACKUP
ALTER DATABASE BEGIN BACKUP;
--   ... take the Everpure Protection Group snapshot now ...
ALTER DATABASE END BACKUP;

Method B — Instance suspend

Suspend I/O at the instance, snapshot, then resume. Keep the suspended window to the few seconds the snapshot needs.

-- As SYSDBA
ALTER SYSTEM SUSPEND;
--   ... take the Everpure Protection Group snapshot now ...
ALTER SYSTEM RESUME;

Trigger the snapshot as a single, coordinated action during the quiesce window shown in Step 3. The snapshot itself is near-instantaneous.

purepgroup snap --suffix "prod-ORCL-appcons-20260316-153000Z" pg-prod-ORCL-rac

Automation wrapper example (the snapshot is commonly issued over SSH, or via REST/SDK from a runner):

Example:
# ./pgroup_snap.sh flasharray01.example.com pg-prod-ORCL-rac prod-ORCL-appcons


ARRAY="${1:?Usage: $0 <array-host> <pgroup-name> [label]}"
PGROUP="${2:?Usage: $0 <array-host> <pgroup-name> [label]}"
LABEL="${3:-appcons}"
SSH_USER="${PURE_SSH_USER:-pureuser}"
 
TIMESTAMP="$(date -u +%Y%m%d-%H%M%SZ)"
SUFFIX="${LABEL}-${TIMESTAMP}"
 
if ssh "${SSH_USER}@${ARRAY}" "purepgroup snap --suffix \"${SUFFIX}\" \"${PGROUP}\""; then
    echo "$(date -u +%FT%TZ) INFO: Snapshot succeeded: ${PGROUP}.${SUFFIX}"
else
    rc=$?
   echo "$(date -u +%FT%TZ) ERROR: Snapshot failed for ${PGROUP} on ${ARRAY} (exit ${rc})" >&2
    exit "${rc}"
fi

Release the database

For multi-array databases, take one Protection Group snapshot per array during the same quiesce window, then recover each with archived redo.

Record snapshot metadata

Post-snapshot validation

Confirm database health and that the snapshot exists:

-- On any RAC instance, as SYSDBA
SELECT status FROM v$instance;        -- expect OPEN
 
-- Check the ASM/DB alert log for errors around the snapshot time
adrci> show alert -tail
# Confirm the Protection Group snapshot was created
purepgroup list pg-prod-ORCL-rac --snap