Skip to main content
Pure Technical Services

Cloning an Oracle Database on VMware VMFS

Currently viewing public documentation. Please login to access the full scope of documentation.



Cloning an Oracle database is one of the common tasks performed by the DBA operations team. Clones of a production database are needed for various business reasons such as creating environments for development, testing, reporting, troubleshooting, etc. This article shows how we can leverage the capability of FlashArray™ snapshots to create clones of an Oracle database on a VMFS (Virtual Machine File System)  datastore. Once a clone is created, the same process can be used to refresh the clone as and when needed.

One of the leading features of the FlashArray is the Purity Snapshot technology. Irrespective of the size of the volume, one can create space-efficient snapshots and copies nearly instantaneously. What that means in the context of Oracle database cloning is that not only can these clones be created in a matter of minutes, irrespective of the source database size, they consume very little space when created. Space consumed by the clones is proportional to the amount of changes that happen on the clones.

VMware Virtual Volumes (vVols) are designed to leverage native capabilities of the FlashArray to the fullest. Each virtual disk is a volume on the array so that all data services of the array are available to it. Virtual volume technology was designed to address the over-abstraction of VMFS and the rigidity of RDMs (Raw Device Mappings). Pure Storage recommends using virtual volumes for running Oracle workloads whenever possible. To get started with VMware vVols on Pure FlashArray, please refer to Virtual Volumes Quick Start Guide.  Virtualize an Oracle Database on VMware using Virtual Volumes goes through the process of migrating an Oracle Database from a physical host to a VMware VM using vVols.

Virtual Volumes were introduced in vSphere 6, so its a relatively new technology. A vast majority of Oracle databases running on VMware VMs are still on VMFS datastores. 

In case of VMFS, a virtual disk (also called VMDK) is essentially a file that is created in the VMFS file system and is presented to the virtual machine to look like a SCSI device. A VMFS datastore can contain virtual disks (vmdk files) for many different VMs. A VMFS datastore is physically stored on a volume on the FlashArray.  Technically, it's possible to add multiple storage volumes to a VMFS datastore. However, to reduce management complexity and overhead, VMware recommends that a datastore consist of a single volume on the array.

Without using the snapshot feature of the FlashArray, the following is one possible way of cloning an Oracle database on VMFS. This method uses VMware VM snapshot feature. The high-level steps are :

  1.  Place the Source database in hot backup mode
  2.  Take a VMware snapshot of the VM hosting Source database
  3.  Take the Source database out of hot backup mode
  4.  Create a Clone VM from the Source VM snapshot
  5.  Startup Cloned VM and perform database recovery to bring up the database.

For large databases, this process (in particular step 4) can take a huge amount of time as copies need to be created of a virtual machine's vmdk and other files. A much more serious drawback of this approach is the fact that VM snapshots are not efficient. Over time one can end up with many snapshots of the production VM, and we know that too many snapshots can slow down a VM (refer to VMware KB 1025279 for best practices). Old snapshots need to be deleted and merged, and that can result in a long freeze of the virtual machine (refer to VMware KB 1002836 for details). This is the last thing one would want to happen to a production server.   

As we can see, the method described above using VM snapshots has several major disadvantages. There is a better way to do this using FlashArray snapshots.

Purity FlashArray snapshots are very useful when there is a need to quickly create clones of an Oracle database. However, because of the many-to-many relationship between VMDKs and FlashArray volumes in a VMFS datastore, we cannot take an array-based snapshot of a virtual disk or a VM. It has to happen at the granularity of the datastore. For this reason, it is recommended that we create a dedicated VMFS datastore for each Oracle database. That way, when we snapshot a VMFS datastore's volume at the array level, we would not be unnecessarily snapshotting virtual disks belonging to other databases or applications.   


Here are the high-level steps for this method :

  1. Identify the storage volume on the FlashArray that comprise the Source database's datastore
  2. Create a volume for the Clone datastore
  3. Attach the Clone Volume to the ESXi host or cluster
  4. Delete the Clone datastore (if doing a database refresh)
  5. Snapshot the Source datastore volume
  6. Copy the Source datastore volume to Clone datastore volume
  7. Create the Clone datastore with a new signature
  8. Setup VM for the Clone database
  9. On the Clone VM, restore the hard disks from the Cloned datastore
  10. Startup the Clone database on the Clone VM


Let's now go over each of these steps in detail:


1. Identify storage volume on the FlashArray that comprise the Source database's datastore  

Go to Storage view, select the Source datastore, and in the details pane on the right, select the Configure tab.  Then select Device Backing to show the Pure FlashArray volume. It displays the Network Addressing Authority (NAA) identifier which contains the serial number of the FlashArray Volume. 




Login to the FlashArray and match the last five digits of the NAA ID with the serial number of the volume to identify the volumes making up the datastore. Make a note of the size and serial number of the Source volume.



2. Create a volume for the Clone datastore

Log into the FlashArray. Go to Storage -> Volumes and click on the plus icon on the Volumes panel to create a volume. Provide a name and size for the Clone volume. The size should be the same as the Source volume.



After the volume is created, click on the volume name link to go to the details page. The serial number is displayed on the Details panel. Make a note of it, particularly the last five characters. 



From the CLI, the same action can be performed as follows.

pureuser@sn1-405-c12-37> purevol create --size 2T oracle-rt-vm-ds-001-clone
Name                       Size  Source  Created                  Serial                  
oracle-rt-vm-ds-001-clone  2T    -       2020-03-28 13:04:06 PDT  4E266CAB708644D600011867


3. Attach Clone volume to the ESXi host or cluster 

As the ESXi host or cluster is already connected to the FlashArray, there already would be a Host and optionally a Host Group on the FlashArray. Connect the newly created volume to it. 

In this case, we have a Host Group for our two ESXi hosts and we will connect the new volume to it. 





From the CLI, use the following command to connect the volume oracle-rt-vm-ds-001-clone to the host group CH06-ESXI-HG.

pureuser@sn1-405-c12-37> purehgroup connect --vol oracle-rt-vm-ds-001-clone CH06-ESXI-HG
Name          Vol                        Lun
CH06-ESXI-HG  oracle-rt-vm-ds-001-clone  253


4. Delete the Clone datastore (in case of a refresh)

If you a doing a refresh of the clone Oracle database, a VM and datastore for the clone would already be existing. 

From the clone VM, delete the virtual Hard Disks that contained the Clone datastore.


Then delete the clone datastore. We will be recreating it after we refresh the underlying FlashArray volumes with a new source snapshot.

Note that we are deleting the Clone datastore at the VMware level, and not the Clone volume on the FlashArray.  


5. Snapshot the Source volume

In Step 1, we identified the volume making up the source datastore. We will create a snapshot of this volume.

To create a snapshot, go to Storage -> Volumes. Click on the source volume to go to the details page. In the Volume Snapshots panel, click on the plus icon.  The following dialog will pop up. Enter an optional suffix for the snapshot name. If left blank, a suffix will be automatically generated.


The cloned database will contain data as of the point in time when the snapshot was taken.

From the CLI, the command to snapshot a volume would look like this.

pureuser@sn1-405-c12-37> purevol snap --suffix clone oracle-rt-vm-ds-001
Name                       Size  Source               Created                  Serial                  
oracle-rt-vm-ds-001.clone  2T    oracle-rt-vm-ds-001  2020-01-28 13:20:09 PDT  4E266CAB708644D600011873


6. Copy the Source volume snapshot to the Clone volume

The snapshot will appear in the Volume Snapshots panel. Click on the Menu icon for the snapshot we just created and select the Copy option.


The following dialog will pop up. Provide the name of the clone volume that we created in Step 2. Since the clone volume already exists, we need to select the Overwrite option.




From the CLI, this is how copying a snapshot to a volume looks like. Note the use of the force option since we want to overwrite the clone volume with latest source snapshot.

pureuser@sn1-405-c12-37> purevol copy --force oracle-rt-vm-ds-001.clone oracle-rt-vm-ds-001-clone
Name                        Size  Source               Created                  Serial                  
oracle-rt-vm-ds-001-clone   2T    oracle-rt-vm-ds-001  2020-01-28 13:20:09 PDT  4E266CAB708644D600011867


7. Create the Clone datastore

Before we create the clone datastore, we need to rescan the storage since the volume for clone datastore has been refreshed.

In the Storage view, highlight the datacenter node and right-click to open the context menu. Select Storage -> Rescan Storage.


Next, select New Datastore option.



The New Datastore dialog pops up. Specify the datastore type as VMFS.



Next, we select the FlashArray volume for the datastore. Select the volume that matches the volume serial number noted in Step 2.  The datastore name that we enter here will be ignored when we re-signature the datastore in the next step, so you can just accept the default.



As this volume has been cloned from the source volume, we need to re-signature it. Select the "Assign a new signature" option.



Select the VMFS version. 



Click Finish to create the Clone datastore.



The new datastore on cloned volumes is created with a cryptic name, not the one we provided to the wizard. 


Right-click on the name to rename it to a user-friendly name.



8. Set up a Virtual Machine for the Clone Database

If you are doing a refresh of the clone database, you would already have the VM in place, so you can step this step. 

In Step 4, we already cleaned it up by deleting the hard disks from the Clone datastore prior to its refresh.


There are various ways of creating a VM for hosting the cloned database.  We will create the VM to host the cloned database by cloning the source VM.  




Specify a name for the clone VM and select a Data Center.



Select which ESXi host the clone VM should run on.



Select a datastore where to create the clone VM. We select the clone datastore



Make sure the Power on virtual machine after creation  checkbox is unchecked. The reason is that we want to replace the hard disks that contain the Oracle database with the snapshot copies.



Click on Finish to create the clone virtual machine.



Once the clone virtual machine is created, follow instructions in Step 4 to drop the old hard disks. 

Also, make sure that the Connect to network checkbox is unchecked so that it does not cause an IP address conflict with the source VM when it is started.

After you have completed Step 9, log in via the console and update the IP address of the clone VM when it is started.


9. Restore the hard disks from the Clone datastore

We now add them back from the refreshed cloned datastore.

Go to the cloned VM Summary tab, and click on Edit Settings.



Identify the vmdk file that corresponds to the dropped disk and select it from the list to add it back.



10. Start the Clone Database on the Clone VM


Once all the disks are added back, restart the clone VM.

If your source database was configured to start automatically, it will startup on the clone.

The SID and dbname from the clone will be the same as the source. Changing the database name and SID are quite easy and the steps are quite well known to DBAs.