The following sections provide an overview of the technologies that are used in this solution for cloning Oracle databases with FlashArray volume snapshots.
Everpure FlashArray
FlashArray is a unified block and file storage solution that delivers an effortless, consistent, and efficient data management experience. Known for its advanced data reduction capabilities, it ensures optimal storage efficiency without compromising performance. Key features of FlashArray include the Evergreen® business model, which allows for seamless upgrades to increase capacity and performance without the need for new storage product purchases, offering long-term value. Additionally, FlashArray is designed with sustainability in mind, reducing direct carbon usage in data storage systems by up to 80 percent compared to competitive all-flash systems, and even more when compared to traditional magnetic disk storage.
FlashArray is tailored to meet diverse business needs and workloads through several distinct offerings:
- FlashArray//C™: An all-quad-level cell FlashArray providing consistent performance with 2–4ms latency, ideal for capacity-oriented workloads
-
FlashArray//X™: Delivers ultra-low latency, as low as 150μs, designed for critical applications and business operations
-
FlashArray//XL™: Offers enterprise-grade performance and scalability, catering to the most demanding workloads
-
FlashArray//E™: Offers an ideal solution for Oracle Database environments that require the performance of all-flash storage but at a more economical price point; designed to optimize storage efficiency without compromising the reliability and speed needed for critical operations
-
Everpure Cloud Dedicated™: A cloud-native block storage solution powered by Purity software, available on your preferred cloud platform.
FIGURE 2 | FlashArray is tailored to meet diverse business needs and workloads through several distinct offerings.
FlashArray Volumes, Snapshots, and Protection Groups
Snapshots are point-in-time images of a volume. A volume itself is a logical storage unit within a FlashArray. Both snapshots and volumes use metadata pointers to reference data blocks on the FlashArray. A protection group is designed to manage and automate the protection of multiple related storage objects, such as volumes. Snapshots can use protection groups to act on multiple volumes concurrently.
Volumes
A FlashArray volume is a block storage object that can be presented to a host, where it appears as a block device. Volumes store user data on a file system managed by the host's operating system. When a FlashArray volume is exported to a host, it allows applications like Oracle Database to read and write data to this storage.
In FlashArray systems, the internal mapping of data for volumes differs from the way it is presented to the user. Rather than directly containing user data, FlashArray volumes maintain metadata pointers that map to data blocks stored in the array's media pool. When a host writes data to a FlashArray volume, the data itself is stored in the media pool, and the volume's metadata is updated to reflect the location of each new data block. This separation means that the user sees a traditional block storage volume, but the actual storage is managed through metadata pointers, which optimizes storage efficiency and enables features like instant snapshots.
This unique architecture allows FlashArray to create snapshots that reference existing data blocks without duplicating them, making snapshots highly space-efficient
Snapshots
Volume snapshots provide a fast, secure, and less-disruptive means to capture data at a particular point in time. When a volume snapshot is taken, FlashArray makes a copy of a volume's metadata such that both the volume and the snapshot point to the same data blocks, without copying the individual data blocks. The data blocks that are referenced by the volume and snapshot become read-only and cannot be changed, which makes the snapshot immutable.
If an Oracle Database host requests a volume write that would change any data block that is referenced by a snapshot, that request is redirected to a new data block. FlashArray updates the volume metadata to point to the new data block, while the previous data block is preserved and referenced by the snapshot.
Protection Groups
While a volume is a logical storage unit within a FlashArray environment, a protection group is designed to manage and automate the protection of multiple related storage objects, such as volumes and hosts.
FIGURE 3 | High-level overview of FlashArray protection groups, volumes, and snapshots.
Oracle Database
Oracle databases work seamlessly with FlashArray, ensuring compatibility and enhanced operational efficiency for database administrators. FlashArray is fully compatible with native Oracle tools, such as Oracle Recovery Manager (Oracle RMAN) and Automatic Storage Management (ASM), allowing Oracle administrators to continue using familiar workflows without disruption. FlashArray snapshots complement Oracle RMAN backup and recovery operations, providing an additional layer of speed and reliability, while also integrating seamlessly with ASM. This combination enables streamlined management of Oracle Database storage, optimizing performance and ensuring efficient database operations.
Cloning Oracle Databases with FlashArray Snapshots
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
└─sda1Using SQL queries (such as SELECT host_name FROM v$instance; and SELECT banner, banner_full FROM v$version;) confirms that the Oracle Database installation matches the source database's version. This prevents incompatibility issues when cloning.
oracle@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>
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)
-
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
By Database Type
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.
Databases' architecture designs and layouts need to be considered to support the requirements listed in this section. For instance, we might need to copy the init.ora files from the source to the target if the directory structures are different.
-
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.
For application-consistent snapshots, the following points apply:
-
The database is quiesced, which causes a brief pause to database input/output operations.
-
Any application-consistent snapshot can be rolled forward to achieve a more granular point-in-time snapshot.
For application-consistent snapshots, do the following:
-
Put the database in backup mode.
-
Take the protection-group snapshot.
-
Take the database out of backup mode.
Refer to the Everpure best practices guide for help setting up Oracle Database on Everpure.