Option C: Clone to an Alternate RAC Cluster

Oracle
Audience
Public
Technology Integrations
Oracle
Source Type
Documentation
This is the recommended procedure for dev/test refreshes, reporting copies, recovery validation, and most non-production use cases. It keeps the source storage and production RAC cluster isolated from the clone.

  1. Prepare the Target Cluster

    Verify the target environment before creating or presenting storage clones:

    • Grid Infrastructure is installed and all target nodes are healthy.

    • Target public, private interconnect, SCAN, and name-resolution configuration is complete.

    • A compatible Oracle Database home is installed.

    • Multipath or NVMe-oF configuration, udev/ASMLib/ASMFD rules, and user permissions are consistent across all target nodes.

    • Target host groups contain only the intended target RAC hosts.

    • Capacity, database services, backup configuration, monitoring, and application isolation are planned.

  2. Create Snapshot-Derived Clone Volumes

    Create a new volume for every database volume in the Protection Group snapshot. Use a naming convention that clearly distinguishes source and clone environments.

    Identify the snapshot using the same commands shown in Step 4.

    # Example source snapshot members to target clone volume names
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-DATA  dev-ORCLDEV-data01
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-FRA   dev-ORCLDEV-fra01
purevol copy pg-prod-ORCL-rac.prod-ORCL-appcons-20260820-153000Z-REDO  dev-ORCLDEV-redo01
    CAUTION:

    Do not clone or present GRID, CRS, or +OCR volumes for the database-clone workflow.

  3. Present Clone Volumes to Target Hosts Only

    Map the new volumes to the target RAC host group. Before presentation, validate that no source production host belongs to that host group.
    # List host groups and confirm current membership
purehgroup list
purehgroup list --host

# Connect each new volume to the target host group
purehgroup connect --vol dev-ORCLDEV-data01  <target_hgroup>
purehgroup connect --vol dev-ORCLDEV-fra01   <target_hgroup>
purehgroup connect --vol dev-ORCLDEV-redo01  <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 step

  4. Rescan and Validate Storage on Every Target Node

    For SCSI-based transports:

    for host in /sys/class/scsi_host/host*; do
  echo '- - -' > "$host/scan"
done
udevadm trigger
multipath -r
multipath -ll

    For NVMe-oF transports:

    nvme list
nvme list-subsys

    Validate the mapping from each presented device to its FlashArray volume through the SCSI WWID or NVMe NGUID. Do not rely only on device names or device enumeration order.

  5. Validate ASM Disk Discovery and Mount Database Disk Groups

    Run as the Grid Infrastructure owner. Confirm candidate and member disks before mounting.

    asmcmd lsdsk
asmcmd lsdg

    Mount only the cloned database disk groups.

    sqlplus / as sysasm

ALTER DISKGROUP DATA MOUNT;
ALTER DISKGROUP FRA MOUNT;
ALTER DISKGROUP REDO MOUNT;
    If ASM reports a disk group identity conflict, stop and correct the isolation or discovery configuration. Do not force-mount a disk group until the source and clone storage paths are understood and the procedure is approved.

  6. Establish a Unique Clone Database Identity

    A clone must not share the source database operational identity. At a minimum, plan a unique DB_UNIQUE_NAME and service names. Depending on the use case and enterprise policy, also change the DBID using Oracle DBNEWID (nid) and update other identifiers or integrations.

    Typical clone changes include:

    • DB_UNIQUE_NAME.

    • DBID, when required for catalog, backup, monitoring, or identity isolation.

    • Database service names.

    • Password file and Clusterware registration.

    • TNS aliases, application connection strings, and SCAN service registrations.

    • Data Guard, backup catalog, monitoring, job scheduler, outbound email, database links, and external integration settings.

    Identity control: Changing only DB_UNIQUE_NAME is not always sufficient. Evaluate DBID and every system that identifies the database by DB name, DBID, service name, host, or application configuration.

  7. Bootstrap a Single Instance

    Start one instance only on one target node. Use a bootstrap PFILE only if the clone cannot use an existing suitable server parameter file or if identity-related parameters must be changed before startup.

    Example bootstrap PFILE for source DB_NAME ORCL and clone DB_UNIQUE_NAME ORCLDEV:

    *.db_name='ORCL'
*.db_unique_name='ORCLDEV'
*.control_files='+DATA/ORCL/CONTROLFILE/current.ctl','+FRA/ORCL/CONTROLFILE/current.ctl'
*.compatible='19.0.0'
*.cluster_database=true
ORCLDEV1.instance_number=1
ORCLDEV2.instance_number=2
ORCLDEV1.thread=1
ORCLDEV2.thread=2
*.diagnostic_dest='/u01/app/oracle'
    Important:

    Oracle Managed Files and ASM directory names commonly retain the source DB name until explicitly changed. Do not assume the clone control files are located under +DATA/<new_db_unique_name>/. Discover the actual files in ASM and use those locations in the initial bootstrap configuration.

    Locate control files when necessary:

    
asmcmd find +DATA '*control*.ctl'
asmcmd find +FRA '*control*.ctl'
asmcmd find +REDO '*control*.ctl'

    Create required diagnostic directories on every target node, then start one instance in mount mode.

    
mkdir -p /u01/app/oracle/admin/ORCLDEV/adump
sqlplus / as sysdba

STARTUP MOUNT PFILE='/home/oracle/clone_bootstrap/initORCLDEV.ora';
SELECT name FROM v$controlfile;
SELECT name FROM v$datafile;

  8. Recover and Open the Clone

    Same as the recovery portion of Step A7: Start, Recover, and Open the Database (RECOVER DATABASE, then ALTER DATABASE OPEN, using RESETLOGS only if the selected recovery procedure requires it), applied to the bootstrapped clone instance.

    After the database opens, confirm its identity and state. This check is clone-specific, since it also verifies DB_UNIQUE_NAME:

    SELECT name, db_unique_name, open_mode, database_role FROM v$database;
SELECT inst_id, instance_name, host_name, status FROM gv$instance ORDER BY inst_id;

  9. Create or Update Password File and SPFILE

    Store the password file and SPFILE in ASM using the target database naming standard. Example:

    Example:

    orapwd file=/home/oracle/clone_bootstrap/orapwORCLDEV password='<secure_password>' format=12

asmcmd mkdir +DATA/ORCLDEV
asmcmd mkdir +DATA/ORCLDEV/PASSWORD
asmcmd mkdir +DATA/ORCLDEV/PARAMETERFILE
asmcmd pwcopy --force /home/oracle/clone_bootstrap/orapwORCLDEV \
  +DATA/ORCLDEV/PASSWORD/orapwORCLDEV

CREATE SPFILE='+DATA/ORCLDEV/PARAMETERFILE/spfileORCLDEV.ora'
  FROM PFILE='/home/oracle/clone_bootstrap/initORCLDEV.ora';

SHUTDOWN IMMEDIATE;

  10. Register the Clone with Clusterware

    Register the database only after the clone opens correctly under controlled single-instance startup and its identity is confirmed.
    srvctl add database \
  -d ORCLDEV \
  -o /u01/app/oracle/product/19.0.0/dbhome_1 \
  -p +DATA/ORCLDEV/PARAMETERFILE/spfileORCLDEV.ora \
  -r PRIMARY \
  -y AUTOMATIC

srvctl add instance -d ORCLDEV -i ORCLDEV1 -n racnode1
srvctl add instance -d ORCLDEV -i ORCLDEV2 -n racnode2

srvctl modify database -d ORCLDEV \
  -pwfile +DATA/ORCLDEV/PASSWORD/orapwORCLDEV

srvctl start database -d ORCLDEV
srvctl status database -d ORCLDEV

    Adjust instance names, node names, database home, and ASM paths to site standards.

  11. Create Clone-Specific Services

    Use target-specific service names and ensure applications cannot accidentally connect to production.

    srvctl add service -d ORCLDEV -s orcldev_app_rw -r ORCLDEV1,ORCLDEV2
srvctl add service -d ORCLDEV -s orcldev_rpt -r ORCLDEV2 -a ORCLDEV1

srvctl start service -d ORCLDEV -s orcldev_app_rw
srvctl start service -d ORCLDEV -s orcldev_rpt
srvctl status service -d ORCLDEV

  12. Post-Clone Controls

    Before providing the clone to users or applications:

    • Disable or redirect outbound integrations, email, file transfers, webhooks, and production-facing database links.

    • Review and disable scheduled jobs that must not run in the clone.

    • Register clone-specific backup and monitoring identities.

    • Confirm Data Guard and replication settings cannot affect production.

    • Apply data masking, access controls, and retention rules required for non-production data.

    • Validate application connection strings, DNS aliases, SCAN, services, and firewall rules.