Creating Snapshots of Virtual Oracle Databases with Everpure FlashArray

Oracle
Audience
Public
Technology Integrations
Oracle
Source Type
Documentation

Overview

​​This document describes practical workflows for creating snapshot-based clones of virtual Oracle databases hosted on Everpure FlashArray in VMware environments. It focuses on Oracle RAC and standalone virtual machine deployments, with emphasis on storage layout, FlashArray protection groups, and datastore or vVol-based cloning methods. ​​

​​The primary design goal is to create fast, space-efficient database copies by using FlashArray snapshots instead of full data duplication. This approach reduces clone creation time, simplifies test and development refreshes, and preserves a clear relationship between Oracle database layout and underlying storage objects. ​​

​​Scope ​​

​​The source content covers three main cloning patterns for virtual Oracle databases on FlashArray. ​​

  • VMware vSphere Virtual Volumes (vVols) workflows, where an Oracle database volume is presented as a vVol and cloned from a protection-group snapshot. ​​

  • ​​Virtual machine disk file workflows, where a database resides on a VMFS-backed virtual machine disk and is cloned from a FlashArray snapshot of the datastore volume. ​​

  • ​​Raw Device Mapping (RDM) workflows, where an Oracle database volume is mapped directly to the virtual machine from the FlashArray and cloned from a protection-group snapshot. ​​

​​Architecture considerations ​​

​​Successful snapshot-based cloning depends on storage layout. When a single virtual disk contains multiple databases, a datastore-level snapshot captures every database on that disk, which limits clone granularity. ​​

​​For per-database cloning, each Oracle database should reside on its own dedicated virtual disk or datastore-backed volume. This layout improves operational isolation and allows administrators to snapshot, clone, and mount only the target database.

Cloning VMware vSphere Virtualized Databases

For virtualized workloads, proper cloning strategies are essential to maintain performance and resource efficiency. This subsection outlines how to adapt snapshot and cloning practices to VMware environments, covering everything from VMware vSphere Virtual Volumes (vVols) to raw device mapping configurations.

VMware vSphere Virtual Volumes (vVols)

  1. Confirm you have a vVol created on the source database server. In the example shown in Figure 16, the cbora1 host does not have any vVols assigned to it; the first step is:

    • Edit the virtual machine settings and select Add new hard disk.

    • The new volume size is 79GB.

    • Under the location table, select the vVol datastore to create the vVol on. In the example shown in Figure 16, we use RedDotX-VVOL.

    • Click OK to create the vVol.

      An example showing that the cbora1 host does not have any vVols assigned to it

  2. The new vVol will be automatically added to the FlashArray using the Everpure plugin. Confirm this with the following:

    1. Select the Volumes tab in the FlashArray user interface.

    2. Under Volume Groups, type the name of the host: cbora1.

    3. The interface displays the new Volume group, called vvol-cbora1-3a6ce8e5-vg.

  3. When you select the volume group, the user interface will show you the vVols inside the volume group. In this example, the main volume we want is the 79GB volume we created when we added the new disk to the virtual machine.

    The user interface displays the new volume group

  4. Confirm the host operating system can see and mount the volumes for Oracle Database, the host can now see the 79GB disk named sdd, and we can see that /dev/sdd1 is mounted on /u02.
    [root@cbora1 ~]#
[root@cbora1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdd 8:48 0 79G 0 disk
└─sdd1 8:49 0 79G 0 part /u02
sdb 8:16 0 80G 0 disk
└─sdb1 8:17 0 80G 0 part
sr0 11:0 1 4.4G 0 rom /run/media/oracle/OL-7.7 Server.x86_64
sdc 8:32 0 50G 0 disk
└─sdc1 8:33 0 50G 0 part
sda 8:0 0 100G 0 disk
├─sda2 8:2 0 99G 0 part
│ ├─ol-swap 252:1 0 9G 0 lvm [SWAP]
│ ├─ol-home 252:2 0 40G 0 lvm /home
│ └─ol-root 252:0 0 50G 0 lvm /
└─sda1 8:1 0 976M 0 part /boot
[root@cbora1 ~]#
[root@cbora1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.8G 637M 7.1G 9% /dev/shm
tmpfs 7.8G 98M 7.7G 2% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/ol-root 50G 35G 16G 69% /
/dev/mapper/ol-home 40G 7.3G 33G 19% /home
/dev/sda1 973M 338M 636M 35% /boot
tmpfs 1.6G 32K 1.6G 1% /run/user/54321
/dev/sdd1 79G 14G 66G 17% /u02
/dev/sr0 4.5G 4.5G 0 100% /run/media/oracle/OL-7.7 Server.x86_64
Oracle Profile
ORACLE_SID=orafs
ORACLE_BASE=/u02/app/oracle
DB_UNIQUE_NAME=orafs
ORACLE_HOME=$ORACLE_BASE/product/19c/dbhome_1
PATH=$PATH:$HOME/.local/bin:$HOME/bin:$ORACLE_HOME/bin
export PS1='`/usr/bin/whoami`@${HOSTNAME}:${PWD} [${ORACLE_SID}]> '
export PATH ORACLE_SID ORACLE_BASE ORACLE_HOME DB_UNIQUE_NAME
  5. Log in to SQL and create a new test table on the source host:
    create table table1 as select * from dba_objects;

    oracle@cbora1.localdomain:/home/oracle [orcl]> sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jan 29 21:51:42 2025
Version 19.5.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL>create table table1 as select * from dba_objects;
Table created.
SQL>select count(*) from table1;
 COUNT(*)
 —-------
 72373
  6. Next, clone the vVol by creating a protection-group snapshot and using the snapshot to create a new volume. In this example, we will use the snapshot with the suffix snap3 to create the clone volume and attach it to host cbora2.

    This example shows the snapshot with the suffix snap3 attached to host cbora2.

  7. Select the virtual machine; in this case, cbora2. If you select vVols, you see no vVols are attached; using the VMware plugin makes it easy to import the snapshot from the FlashArray:

    • Select import diskhen search for the virtual machine that the source vVols are on; in this example, cbora1.

    • Expand the hard disk to get a listing of the recent snapshots; in this example, hard disk 4.

    • Select the snapshot from the suffix snap3, and then import the clone.

      Selecting the correct snapshot and importing the clone

  8. The new volume import displays as a vVol.

    The new volume import displays as a vVol.

  9. As shown in Figure 20, the new clone disk /dev/sde appears with the XFS file system, which has been mounted on /u02.
    [root@cbora2 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdd 8:48 0 80G 0 disk
└─sdd1 8:49 0 80G 0 part
sdb 8:16 0 80G 0 disk
└─sdb1 8:17 0 80G 0 part
sr0 11:0 1 4.4G 0 rom
sde 8:64 0 79G 0 disk
└─sde1 8:65 0 79G 0 part /u02
sdc 8:32 0 50G 0 disk
└─sdc1 8:33 0 50G 0 part
sda 8:0 0 100G 0 disk
├─sda2 8:2 0 99G 0 part
│ ├─ol-swap 252:1 0 9G 0 lvm [SWAP]
│ ├─ol-home 252:2 0 40G 0 lvm /home
│ └─ol-root 252:0 0 50G 0 lvm /
└─sda1 8:1 0 976M 0 part /boot
[root@cbora2 ~]#
[root@cbora2 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.7G 637M 7.1G 9% /dev/shm
tmpfs 7.7G 106M 7.6G 2% /run
tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup
/dev/mapper/ol-root 50G 35G 16G 70% /
/dev/mapper/ol-home 40G 11G 30G 26% /home
/dev/sda1 973M 440M 534M 46% /boot
tmpfs 1.6G 12K 1.6G 1% /run/user/42
tmpfs 1.6G 0 1.6G 0% /run/user/54321
/dev/sde1 79G 14G 66G 17% /u02
  10. Make sure the correct Oracle profile is set to point to the correct Oracle system identifier and Oracle home.
    Oracle Profile
ORACLE_SID=orafs
ORACLE_BASE=/u02/app/oracle
DB_UNIQUE_NAME=orafs
ORACLE_HOME=$ORACLE_BASE/product/19c/dbhome_1
PATH=$PATH:$HOME/.local/bin:$HOME/bin:$ORACLE_HOME/bin
export PS1='`/usr/bin/whoami`@${HOSTNAME}:${PWD} [${ORACLE_SID}]> '
export PATH ORACLE_SID ORACLE_BASE ORACLE_HOME DB_UNIQUE_NAME
    SQL> select name from v$database;
NAME
—---
ORAFS
SQL> select count(*) from table1;
 COUNT(*)
----------
 7237

Virtual Machine Disk Files

Cloning databases on virtual machine disks can be challenging if you are after a granular level of cloning, such as perdatabase. Most existing or legacy VMware environments have multiple databases on a single virtual machine disk with this type of configuration. When we take a protection group snapshot of the datastore volumes, we snapshot all the databases.

If we are looking to only snapshot and clone a single database, then that database needs to be on its own virtual machine disk datastore. The following example walks through setting up a database per virtual machine disk and cloning that database.

  1. Identify the storage volumes on the FlashArray that make up the source database volumes.

  2. Create the volumes of the clone databases, either from the snapshots of the source volumes or from scratch.

  3. Attach the clone volumes to the VMware ESX host or cluster.

  4. Copy the source datastore volume to the clone datastore volume.

  5. Create the clone datastore with a new signature.

  6. Set up the virtual machine for the clone database, and then attach clone volumes.

  7. Start up the clone database.

  8. Identify the source volumes that make up the virtual machine disk datastore.

    • In the example shown in Figure 21, the volume of the source datastore is called ora-ds-vmdk-cb, it's connected to SYD-Demo-Cluster1, the logical unit number is 175, and the serial number ends in C1DE.

      Identify the source volumes that make up the virtual machine disk datastore.

    • Confirm the device back end from the VMware ESX environment. Figure 22 shows the correct logical unit number; it matches the serial number from Figure 21.

      Confirm the device back end from the VMware ESX environment

  9. Confirm the Oracle virtual machine, ora5, is using the correct virtual machine disk. Figure 23 shows a 100GB disk created on the virtual machine disk called ora-ds-vmdk-cb, which is mounted on the ora5 Linux host.

    Confirm the Oracle virtual machine, ora5, is using the correct virtual machine disk

  10. Create the protection group for the virtual machine disk datastore volumes, and then add the datastore volume ora-dsvmdk-cb to the protection group.

    Creating a protection group and adding the volume to it.

  11. Take the protection-group snapshot; the example in Figure 25 uses the suffix snap1 to create the protection-group snapshot; the snapshot name is ora5-pg.snap1.ora-ds-vmdk.cb.

    Take the protection group snapshot.

  12. Create a new clone volume of the datastore volumes from the protection-group snapshot. Note that the volume is called oradf-vmdk-clone-db; this will be the new name for the clone datastore. The volume is connected to the SYD-Demo-Cluster with serial number C553.

    Create a new clone volume of the datastore volumes from the protection-group snapshot.

  13. Once the clone volume is attached to the host, scan for new volumes using the VMware ESX cluster.

    Scan for new volumes using the VMware ESX cluster.

  14. Create a new datastore from the clone volume:

    • Select New Datastore.

    • Select VMFS.

    • Enter the new clone datastore name, ora-ds-vmdk-clone-cb using LUN 174 S/N C553.

      Create a new datastore for the clone volume.

  15. Because we are cloning an existing datastore, we need to write a new signature to the datastore; otherwise, we will get a signature conflict error.

    Write a new signature to the datastore to avoid a signature conflict error.

  16. The new clone datastore is imported with the new name allocated to it. We can now use this datastore to present the clone disk to the same virtual machine or to another virtual machine. In the example shown in Figure 30, we present the clone disk to a new host called ora5-clone.

    The new clone datastore is imported with the new name allocated to it

  17. Select the new ora5-clone virtual machine, click Actions, and then click Edit settings.

  18. Select Add device.

  19. Select Existing hard drive.

  20. You will see the new clone datastore. Select the datastore and then the ora5-vmdk disk to attach.

    Showing the new clone datastore.

  21. The new disk is now attached to the ora5-clone virtual machine. We can confirm this from the Edit Settings tab, which also shows that the operating system can see the new 100GB clone volume.

    The new disk is now attached to the ora5-clone virtual machine, as seen in the Edit Settings tab

  22. Mount the volume, start up the Oracle database, and confirm that the table we created on ora5 is present.
    mkdir /u01
mount /dev/sdb1 /u01
su - oracle
sqlplus / as sysdba
select count(*) from tb1;
[oracle@ora5-clone ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 7.8G 26M 7.7G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/ol-root 50G 7.4G 43G 15% /
/dev/sda1 1014M 314M 701M 31% /boot
/dev/mapper/ol-home 42G 39M 42G 1% /home
tmpfs 1.6G 4.0K 1.6G 1% /run/user/42
tmpfs 1.6G 44K 1.6G 1% /run/user/1000
/dev/sdb1 100G 11G 90G 11% /u01
/dev/sdc1 50G 743M 50G 2% /u02
tmpfs 1.6G 0 1.6G 0% /run/user/54321
    [oracle@ora5-clone ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 30 08:52:18 2025
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL>
SQL> select count(*) from tb1;
 COUNT(*)
----------
 72373

Raw Device Mappings

Raw Device Mapping (RDM) is a VMware vSphere feature that presents a FlashArray volume directly to a virtual machine as a block device, bypassing the VMFS datastore layer used by VMDK files. From the guest operating system's perspective, the volume appears as a SCSI disk that retains the FlashArray volume's native serial number, preserving a one-to-one correspondence between the guest's disks, the VM's virtual devices, and the underlying array volumes. This direct alignment simplifies snapshot-based cloning and recovery, because the volumes a database administrator clones on the array correspond exactly to the disks the guest sees and mounts.

For Oracle workloads, this model fits naturally with the FlashArray protection-group snapshot workflow. Source database volumes are grouped on the array, snapshotted as a write-consistent set, copied onto pre-provisioned clone volumes, and presented to a target virtual machine as RDMs without involving a VMFS datastore. The procedure below walks through this end to end: identifying the source volumes, taking the protection-group snapshot, copying it to the clone volumes, attaching the clones to the target VM, and bringing the cloned Oracle database online.

  1. Identify the storage volumes on the FlashArray that make up the source database volumes and add those volumes to a protection group.

  2. Take the protection-group snapshot of the source database volumes.

    The copy-to data and file-recovery area with a new volume.

  3. Copy the individual snapshots to the new clone volumes; in this example, we copy orpag-clone-ora1-data to ora4-data and ora4-fra.
    purevol copy snapshot-name ora4-data
purevol copy snapshot-name ora4-fra

    Copy the individual snapshots to the new clone volumes.

  4. Take note of the new volumes and the serial numbers allocated with the new volumes; these will be used in VMware to allocate volumes to the virtual machine.

  5. Connect the new clone volumes to the VMware ESX cluster host group.

    Connect the new clone volumes to the ESXi cluster host group.

  6. Log in to the VMware vSphere environment, and then select the new virtual machines to use as the target for cloned volumes; in the example shown in Figure 36, this is the ora4 virtual machine.

    Select the new virtual machines to use as the target for cloned volumes.

  7. Create a Secure Shell connection to the Oracle virtual machine and confirm there are no clone volumes attached. In this example, we can see that only the boot volume is shown:
    su -
# lslbk
    [root@ora4 ~]#
[root@ora4 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 99G 0 part
 ├─ol-root 249:0 0 50G 0 lvm /
 ├─ol-swap 249:1 0 7.9G 0 lvm [SWAP]
 └─ol-home 249:2 0 41.1G 0 lvm /home
sr0 11:0 1 4.1G 0 rom/run/media/oracle/OL-7.5 Server.x86_64

  8. Select the ora4 virtual machine in the vSphere console.

  9. Right-click the Actions tab, and then select Edit settings.

  10. Select Add new device, and then select RDM.

  11. Figure 37 highlights the new clone volumes needed, with the serial numbers confirmed previously (e3ab0 and e3aaf).

    Showing the new clone volumes needed.

  12. We can now see the new hard disks allocated to the virtual machine (the 300GB and 100GB disks). We can also see the output of the lsblk command, which shows us the new volumes attached with the correct serial numbers. Because they are clones, we can also see the Logical Volume Manager names.
    # lsblk -o name,serial

    The raw volume details.

    [root@ora4 ~]#
[root@ora4 ~]# lsblk -o name,serial
NAME SERIAL
sda
├─sda1
└─sda2
 ├─ol-root
 ├─ol-swap
 └─ol-home
sdb 624a9370a21265762db64ece008e3ab0
└─sdb1
 └─orafravg-orafra
sdc 624a9370a21265762db64ece008e3aaf
└─sdc1
 └─oradatavg-oradata
sr0 00000000000000000001
[root@ora4 ~]#

  13. On the Oracle host, mount the new clone volumes.

  14. Confirm the volumes are mounted and the file systems are consistent with the source host.

  15. Switch to the Oracle user, source the .bash_profile, and then run the sqlplus command to start Oracle:
    sqlplus / as sysdba

    # mount /dev/mapper/oradatavg-oradata /u01
# mount /dev/mapper/orafravg-orafra /u02
[root@ora4 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 7.8G 18M 7.7G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/ol-root 50G 6.9G 44G 14% /
/dev/mapper/ol-home 42G 43M 42G 1% /home
/dev/sda1 1014M 329M 686M 33% /boot
tmpfs 1.6G 36K 1.6G 1% /run/user/54321
/dev/sr0 4.2G 4.2G 0 100% /run/media/oracle/OL-7.5 Server.x86_64
tmpfs 1.6G 0 1.6G 0% /run/user/1000
/dev/mapper/oradatavg-oradata 296G 24G 257G 9% /u01
/dev/mapper/orafravg-orafra 99G 671M 93G 1% /u02
[root@ora4 ~]#

  16. Confirm Oracle Database starts up, and then select the mode of the database to confirm it is in read/write mode.

  17. Select the name of the database; in this example, orcl, which is the name of the source database.
    Note: Depending on your environment and what you trying to do, the name can be left for the purpose of testing or you can change the name.

  18. To change the database name, use the NID command provided by Oracle, and then complete the following steps:

    • Start in mount mode.

    • Run the NID command with the new target database name.
      [oracle@ora4 ~]$
[oracle@ora4 ~]$ sqlplus / as sysdba
SQL> startup mount;
Total System Global Area 4966053832 bytes
Fixed Size 8906696 bytes
Variable Size 1157627904 bytes
Database Buffers 3791650816 bytes
Redo Buffers 7868416 bytes
Database Mounted.
SQL>
oracle@ora4 ~] nid TARGET=sys/oracle123 DBNAME=devdb
DBNEWID: Release 19.0.0.0.0 - Production on Thu Jan 30 09:20:43 2025
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Connected to server version 19.3.0
Control Files in database:
 /u01/app/oracle/oradata/ORCL/controlfile/ol_mf_gj74s43x_.ctl
 /u02/fast_recovery_area/ORCL/controlfile/ol_mf_gj74s44y_.ctl
Change database ID and database name ORCL to DEVDB? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 1538741700 to 1095587148
Changing database name from ORCL to DEVDB
 Control File /u01/app/oracle/oradata/ORCL/controlfile/ol_mf_gj74s43x_.ctl - modified
 Control File /u02/fast_recovery_area/ORCL/controlfile/ol_mf_gj74s44y_.ctl - modified
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_system_gj74nsbv_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_tsdemo_gqovfmhx_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_sysaux_gj74pjjq_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_undotbs1_gj74qmng_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_iops_gqlwmt7r_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_users_gj74qnrc_.db - dbid changed wrote new name
 Datafile /u01/app/oracle/oradata/ORCL/datafile/ol_mf_temp_gq74sd4y_.db - dbid changed wrote new name
 Control File /u01/app/oracle/oradata/ORCL/controlfile/ol_mf_gj74s43x_.ctl - dbid changed, wrote new name
 Control File /u02/fast_recovery_area/ORCL/controlfile/ol_mf_gj74s44y_.ctl - dbid changed, wrote new name
 Instance shut down
Database name changed to DEVDB
Modify parameter file and generate a new password file before restarting
Database ID for database DEVDB changed to 1095587148
All previous backups and archived redo logs for this database are unusable
Database is not aware of previous backups and archive logs in Recovery Area
Database has been shutdown, open database with RESETLOGS option
Successfully changed database name and ID
DBNEWID - Completed successfully
      SQL> alter database open resetlogs;
Database altered.
SQL>
SQL> exit.
[oracle@ora4 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 30 09:13:11 2025
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL>
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE
SQL>
SQL>
SQL> select name from v$database;
NAME
---------
DEVDB
SQL>

Conclusion

The workflows in this document demonstrate how Everpure FlashArray snapshots, vVols, VMFS, and RDMs can be combined to deliver fast, repeatable cloning of virtual Oracle databases with minimal operational overhead. By standardizing database layout on dedicated storage objects and using protection‑group–based snapshots as the control point, operations teams gain predictable, low‑risk refresh processes for development, test, and QA environments without sacrificing performance or resiliency.