Cloning an Oracle database involves creating an exact replica of the database at a specific point in time. This process is widely used for database refreshes, enabling development and testing environments to work with data that mirrors production systems. Cloning is also essential for disaster recovery, where identical copies can be deployed as recovery instances in the event of a failure, and for analytics and reporting, where clones can be used to offload resource-intensive queries without impacting production performance.
Cloning solutions that leverage FlashArray volume snapshot copy/clone procedures ensure minimal downtime, reduced administrative overhead, and seamless support for scenarios that require frequent database replication.
Prerequisites and Considerations
This section describes the foundational elements necessary for a smooth and effective cloning process using FlashArray. By addressing key storage and database configurations upfront, organizations can avoid common pitfalls and optimize the cloning procedure to align with their operational requirements and resources.
Storage Type
Understanding whether databases reside on file system–based storage or ASM is crucial for configuring snapshots and preventing performance or compatibility issues. This section describes how each storage type influences snapshot cloning workflows.
Regardless of the storage type, it must be confirmed that the assigned volumes are accessible and that the Oracle binary versions match those of the source environment.
Verifying Assigned Volumes
FIGURE 4 | Volumes assigned to host groups, including their serial numbers.
[root@cbora2 ~]#
[root@cbora2 ~]#
[root@cbora2 ~]# lsblk -o name,model,serial
NAME MODEL SERIAL
sdd FlashArray 624a93703bc12bfc226b41c300751634
└─sdd1
sdb FlashArray 624a93703bc12bfc226b41c3000f98bd
└─sdb1
sr0 VMware SATA CD00 00000000000000000001
sde Virtual disk
└─sde1
sdc FlashArray 624a93703bc12bfc226b41c3000f98be
└─sdc1
sda Virtual disk
├─sda2
│ ├─ol-swap
│ ├─ol-home
│ └─ol-root
└─sda1oracle@cbora1.localdomain:/home/oracle [orcl]> sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 30 11:16:44 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> select host_name from v$instance;
HOST_NAME
----------------------------------------------------------------
cbora1.localdomain
SQL>
SQL> select banner,banner_full from v$version;
BANNER
--------------------------------------------------------------------------------
BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
oracle@cbora2.localdomain:/home/oracle [orcl]> sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 30 11:17:59 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> select host_name from v$instance;
HOST_NAME
----------------------------------------------------------------
cbora2.localdomain
SQL>
SQL>
SQL> select banner,banner_full from v$version;
BANNER
--------------------------------------------------------------------------------
BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL>File System
Before cloning an Oracle database on a file system–based environment, make sure the following conditions are met to ensure a smooth and efficient process:
-
Validated file system paths: Verify that the file system paths and mount points match your intended directory structure, ensuring the clone can locate datafiles and logs without errors.
-
Initialization file updates: Copy the init.ora file from the source to the target and adjust paths or parameters to align with the target server's configuration.
-
Resource availability: Ensure the target host has sufficient CPU, memory, and input/output resources to handle cloning operations alongside production workloads without degradation.
-
Correct Oracle Database permissions: Confirm that file system permissions (ownership, group memberships, and access modes) are set appropriately for the Oracle Database user and any related service accounts.
-
Granular cloning on virtual machine disks: When Oracle file systems reside on virtual machine disks and finer cloning control is needed, use a dedicated virtual machine file system datastore per Oracle Database. This approach simplifies snapshot and clone management.
Oracle Automatic Storage Management (ASM)
Before cloning an Oracle database on ASM storage, ensure the following:
-
Persistent device names and permissions: Configure your system (using UDEV rules or Oracle's ASMLib) so that device names and permissions remain consistent across reboots.
-
Filter driver compatibility: If using the Oracle ASM Filter Driver, verify compatibility with your Linux kernel version by checking the ASM Filter Driver certification matrix.
-
Renaming disk groups: When cloning to the same host, rename the disk group to prevent conflicts with the source.
-
VMware environments: If ASM resides on virtual machine disks and granular cloning is required, dedicate a separate VMware vSphere VMFS datastore for each Oracle Database instance.
Database Type
Different Oracle Database architectures have unique dependencies and requirements. Grasping these distinctions up front helps users tailor their cloning strategies to each environment, ensuring consistency, optimal resource usage, and minimal risk.
Single-Instance Traditional/Standalone
When working with a single-instance Oracle Database environment, verify that the following considerations and prerequisites are in place to ensure a reliable cloning process:
-
Crash-consistent state: The database should be crash-consistent at snapshot time, meaning all data files, online redo logs, and control files must be in sync to reflect a consistent point in time.
-
Volume requirements: Provision the necessary volumes for data files and any external files or configurations the database relies on. While there are structural differences between ASM and file system–based environments, additional volumes beyond the primary data areas are not typically required for ASM.
-
Parameter review: Make certain that initialization parameters, security settings, custom configurations, and database options used in the source are replicated. This preserves the functionality and performance characteristics in the cloned environment.
-
Backup and testing: Creating a backup of the source database before cloning is highly recommended. Where possible, perform a test run in a non-production environment to validate the cloning workflow and mitigate risks.
-
No hot backup mode required: As long as the scenario uses Oracle Database 12c Release 2 and above, the database does not need to be placed in hot backup mode for FlashArray snapshot cloning, provided the database is in a restorable state.
The high-level steps for cloning a single instance or standalone database are as follows:
-
Prepare the source database: Take a protection-group snapshot of the source database.
-
Shut down the target database: Stop the target database to prevent conflicts.
-
Take the target volumes offline: − Take the ASM disk groups offline. − Unmount the file systems.
-
Copy snapshots to target volumes: Use FlashArray snapshots to replicate or overwrite the target volumes.
-
Bring the target volumes online: − Take the ASM disk groups online. − Mount the file systems.
-
Start and verify the cloned database: Start the database and confirm it is operational.
Single-instance Pluggable Database and Container Database
When performing granular-level cloning of container databases and pluggable databases, the following requirements and considerations must be addressed:
-
ASM configurations: Each pluggable database must reside on its own ASM disk group (for example, PDB1, PDB2, and PDB3) to enable individual cloning.
-
File system configurations: Each pluggable database should be configured on a separate file system (for example, / PDB1, /PDB2, and /PDB3) for clear data separation
The high-level steps for cloning a single-instance pluggable database or container database are as follows:
-
Create the pluggable database on the specified volume; if the volume is ASM, then specify the ASM disk group; if it's a file system, then specify the file system mountpoint.
-
Take a protection-group snapshot of the ASM disk groups or file systems containing the container database or pluggable database data.
-
Shut down the target database, offline the ASM disk group, and unmount the file system.
-
Replicate the snapshot to the target environment by assigning it to the target volumes.
-
Bring the target volumes online: − Take the ASM disk groups online. − Mount the file systems containing the cloned data.
-
Start the Oracle database.
-
Confirm the pluggable databases are on their respective ASM disk groups or file systems.
-
Open the pluggable database and validate the replicated data
Oracle Real Application Clusters (Oracle RAC)
Oracle Real Application Clusters (Oracle RAC) is a database clustering solution that enables multiple servers (nodes).
-
Shared storage awareness: Confirm that all Oracle RAC nodes are aware of, and properly configured to access, the shared storage.
-
Version consistency: Ensure all Oracle RAC nodes are running the same Oracle Grid Infrastructure and Oracle Database versions to avoid compatibility issues.
-
Network configuration: Validate that the interconnect and public network configurations are consistent across all nodes.
-
Disk group availability: Ensure all required ASM disk groups are accessible from every Oracle RAC node.
The high-level steps for cloning an Oracle RAC database are as follows:
-
Ensure the source Oracle RAC database is in a crash-consistent state and all nodes are aware of the shared ASM disk groups.
-
Take snapshots of the ASM disk groups containing the database files.
-
Replicate the ASM snapshots to the target Oracle RAC environment.
-
Confirm all target Oracle RAC nodes have the same Oracle Grid Infrastructure and Oracle Database versions as the source.
-
Take the ASM disk groups online for on all target Oracle RAC nodes.
-
Adjust initialization parameters and reconfigure cluster resources as needed for the target environment.
-
Start the database on the target Oracle RAC cluster and verify functionality across all nodes.
Initial Steps: Creating Snapshots
Volume snapshots are the backbone of the cloning process. This section outlines the critical steps to capture clean, reliable snapshots on FlashArray, forming the starting point for any successful clone. This includes describing how best to prepare and execute these snapshots across various storage and database configurations.
By Storage Type
Each storage approach has unique mechanics for snapshot creation. By following targeted guidance, readers can ensure that snapshots are created efficiently, remain consistent, and align with best practices for their specific storage setup.
File System–based Storage
-
Identify the source database host volumes from the FlashArray user interface.
-
In the example shown in Figure 5, the volumes ora1-data and ora1-fra are connected to the host group SYD-Demo-Cluster1, which includes the three hosts ESX01, ESX02, and ESX03.
FIGURE 5 | File system-based storage snapshots
-
Confirm the source volume serial numbers on the array match the volumes on the source host. Figure 6 shows that the volumes match:
-
The volume with a serial number ending in 16C19 is logical volume oradatavg-oradata, mounted on /U01.
-
The volume with a serial number ending in 16C1A is logical volume orafravg-orafra, mounted on /U02.
-
This is confirmed via the lsblk command output, which matches the user interface.
FIGURE 6 | Confirm the source volume serial numbers on the array match the volumes on the source host
[root@ora1 ~]# [root@ora1 ~]# lsblk -o name,model,serial NAME MODEL SERIAL sda Virtual disk ├─sda1 └─sda2 ├─ol-root ├─ol-swap └─ol-home sdb FlashArray 624a9370a21265762db64ece00016c19 └─sdb1 └─oradatavg-oradata sdc FlashArray 624a9370a21265762db64ece00016c1a └─sdc1 └─orafravg-orafra sdd FlashArray 624a9370a21265762db64ece00016c1b └─sdd1 └─orafravg1-orafra1 sr0 VMware SATA CD00 00000000000000000001 [root@ora1 ~]# [root@ora1 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 5.8G 0 5.8G 0% /dev tmpfs 5.8G 0 5.8G 0% /dev/shm tmpfs 5.8G 74M 5.7G 2% /run tmpfs 5.8G 0 5.8G 0% /sys/fs/cgroup /dev/mapper/ol-root 49G 12G 38G 24% / /dev/sda1 1014M 321M 694M 32% /boot /dev/mapper/ol-home 40G 3.0G 37G 8% /home /dev/mapper/oradatavg-oradata 296G 24G 257G 9% /u01 /dev/mapper/orafravg-orafra 99G 671M 93G 1% /u02 tmpfs 1.2G 12K 1.2G 1% /run/user/42 tmpfs 1.2G 0 1.2G 0% /run/user/54321Figure 7 shows the user interface displaying the protection group name, volumes in the group, and the last three snapshots.Identifying Volumes purevol = purevol list ora1 -data ora1-fra # Identify the source volumes df -k = /dev/mapper/oradatavg-oradata 296G 24G 257G 9% /U01 # File system mounted on /U01 df -k = /dev/mapper/orafravg-orafra 99G 671M 93G 1% /U02m # File system mounted on /U02 Creating the Protection Group
purepgroup = puregroup create orapg # Create orapg protection group Adding the Volumes to the Protection Group purevol = purevol add --pgroup orapg ora1- data ora1-fra # Add volumes to protection group Listing the Protection Group purepgroup = purepgroup list orapg # List orapg protection group contents Taking a Protection Group Snapshot purepgroup = purepgroup snap orapg # Take a protection group snapshot Listing the Last Three Protection Group Snapshots purepgroup = purepgroup list –snap orapg –limit 3 # List the three latest snapshots FIGURE 7 | The Oracle protection group, its component volumes, and the most recent snapshots.
-
-
To create a snapshot from the user interface, click the + icon under Source Protection Group Snapshots. Assigning a suffix to the snapshot name is optional.
FIGURE 8 | Creating a snapshot from the user interface.
ASM-based Storage
The process of capturing protection group snapshots for ASM is the same as for the file system, as all volumes appear identical from the array's perspective. Table 2 outlines the commands for the protection group's preparation.
The most important points to remember are to identify the correct volumes for the source database and to add those volumes to the protection group. The identification process is the same as for file systems:
-
Make sure the disk serial numbers on the host match the volumes on the array. For example, the following command will print the disk device and serial from the array:
# lsblk -o name,serial -
Make sure the correct disks are allocated to the respective ASM disk groups.
-
Make sure the correct volumes on the array that are assigned to the host are in the protection group.
Command Example Description Identifying the Volumes on the Source purevol = purevol list cbora1-data cbora1-fra # Identify the source volumes asmcmd = lsdg # List the ASM disk group Code: Creating the Protection Group purepgroup = puregroup create asmora # Create asmora protection group Adding the Volumes to the Protection Group purevol = purevol add --pgroup asmora cbora1-data cbora1-fra # Add volumes to protection group Listing the Protection Group purepgroup = purepgroup list asmora # List asmora protection group contents Taking a Protection Group Snapshot purepgroup = purepgroup snap asmora # Take a protection group snapshot List the Last Three Protection Group Snapshots purepgroup = purepgroup list –snap asmora –limit 3 # List the three latest snapshots
Whether dealing with simple standalone instances or more complex container- or cluster-based environments, taking snapshots correctly is critical. This section focuses on best practices for each database type, ensuring cloning workflow reliability.
Single-instance Traditional/Standalone and Container Database/Pluggable Database
Once the initial source and target environments are set up, we are ready to clone the database. The following workflow outlines the required steps.
-
Verify the target volumes' file systems are unmounted.
-
Verify the target database is shut down.
-
Create the crash-consistent protection-group snapshot of the source volumes.
-
Copy/overwrite the target volumes with the source volume snapshots.
-
Mount the target file systems.
-
Start the database on the target server
ASM
-
Verify that the target volumes' ASM disk groups are offline.
-
Verify that the target database is shut down.
-
Create the crash-consistent protection-group snapshot of the source volumes.
-
Copy/overwrite the target volumes with the source volume snapshots
-
Bring the target ASM disk groups online.
-
Start the database on the target server
The only difference between the process for a file system and ASM is the unmount and offline commands; the rest of the steps are identical.
Everpure snapshots conform to the requirements for crash-consistent snapshots described in Oracle's MOS document 604683.1. That is, crash-consistent snapshots include time stamps of all volumes that demonstrate they are identical and write ordering is maintained. Crash-consistent snapshots, also referred to as "point-in-time" snapshots, capture the state of the datafiles on disk; that is, they do not capture updates in-memory/mid-flight.