Option B: Restore to New Volumes on the Same Cluster

Oracle
Audience
Public
Technology Integrations
Oracle
Source Type
Documentation

This option preserves the source volumes while making a snapshot-derived volume set available to the same RAC cluster. It is safer than in-place overwrite, but it still requires strict identity and resource control because a clone cannot run alongside the source database on the same cluster with the same database identity.

Use Option B for a controlled storage cutover, validation before overwrite, or a same-cluster recovery workflow. For ordinary dev/test refreshes, prefer Option C instead.

  1. Stop the Source Database

    Same as Step 2: Stop Database Resources above. Stop the source database and confirm all instances and services are stopped before proceeding.

    If the restored clone volumes will replace the active volume set, also dismount the original database disk groups as described in Step 3: Dismount the Database ASM Disk Groupsabove.

  2. Create New Volumes from the Snapshot

    Create a new volume for each snapshot member. Use a clear, unique naming convention that identifies source database, disk group, purpose, and timestamp.

    Identify the snapshot using the same commands shown in Step 4: Overwrite the Active Volumes from the Snapshot.

    # Example only: create new volume clones from snapshot members
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-DATA  rcv-ORCL-data-20260820
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-FRA   rcv-ORCL-fra-20260820
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-REDO  rcv-ORCL-redo-20260820
    Note:

    Use the exact copy syntax and snapshot object names supported by the deployed Purity CLI/API version. The essential control is one new destination volume per source snapshot member, created from the same Protection Group snapshot poi

  3. Present New Volumes to All RAC Nodes

    Map each new volume to the same host group that contains the intended RAC nodes. Ensure LUN IDs or NVMe namespace mappings meet local standards and are consistent across every cluster node.

    # List host groups and confirm current membership
purehgroup list
purehgroup list --host

# Connect each new volume to the target host group
purehgroup connect --vol rcv-ORCL-data-20260820  <target_hgroup>
purehgroup connect --vol rcv-ORCL-fra-20260820   <target_hgroup>
purehgroup connect --vol rcv-ORCL-redo-20260820  <target_hgroup>

# Verify the volume-to-host-group mapping and LUN assignment
purehgroup list --connect <target_hgroup>
    Note: Host-group command names and syntax vary by Purity version. After connecting, confirm every intended RAC node sees the same LUN for the same volume before moving to the rescan ste

    Before presenting the volumes, confirm that:

    • The original active volumes will not be confused with the clone volumes.

    • The cloned volume names are unique.

    • ASM discovery rules will identify the new devices predictably.

    • The source database is stopped and no competing ASM disk group uses the cloned disk headers.

  4. Rescan and Validate Devices

    Run the appropriate discovery commands on every target RAC node.
    # SCSI/FC rescan example
for host in /sys/class/scsi_host/host*; do
  echo '- - -' > "$host/scan"
done
udevadm trigger
multipath -r
multipath -ll
    For NVMe-oF, rescan or reconnect according to the deployed transport and host configuration, then validate namespaces and paths.
    nvme list
nvme list-subsys
    Validate device ownership, permissions, udev aliases, or ASMLib labels before proceeding.

  5. Verify ASM Discovery Without Mounting Unintentionally

    Run as the Grid Infrastructure owner.

    asmcmd lsdsk
asmcmd lsdg

    Confirm that every clone device is visible and that the expected disk headers and disk group membership are present. Do not initialize, relabel, or execute createdisk on a cloned ASM disk as it already contains ASM metadata.

    Same-cluster control: A cloned ASM disk group has the same disk group identity as its source. Do not attempt to mount both original and cloned copies concurrently in the same ASM cluster. Choose one complete volume set for the active database or use an alternate cluster.

  6. Activate the New Volume Set

    Follow the approved cutover procedure to make the clone set the active database storage. Once the original disk groups are dismounted and the source volume paths are no longer eligible for ASM discovery, mount the cloned database disk groups.

    -- As SYSASM; execute only for the intended clone volume set
ALTER DISKGROUP DATA MOUNT;
ALTER DISKGROUP FRA MOUNT;
ALTER DISKGROUP REDO MOUNT;

    Then follow the recovery and validation sequence in Steps A7 and A8.