Database Cloning Using Pure Storage
by Jeff Stonacek, Principal Architect
Cloning an Oracle database that is running on Pure Storage can be done through Pure’s snapshot and copy technologies. Snapshots are taken of the source database volumes and then copied to the target volumes. There is no actual data movement, so the commands are instantaneous.
At a high level, the process to clone an Oracle database looks like this:
- Shutdown the target database, if running
- Unmount the target filesystems
- Remove the snapshots on the source volumes, if present
- Take new snapshots of the source volumes
- Copy the snapshot source volumes to the target volumes
- Mount the target filesystems
- Recreate the control file for the target database
- Startup the target database with the “resetlogs” option
Typically, the only filesystems that are required for cloning an Oracle database are datafiles and undo. So, the redo logs are not needed for a clone. However, the snapshot and copy technologies leave the target datafiles in a crash consistent state. Meaning, they will need to be recovered to become consistent. This blog assumes a rename of the Oracle database on a separate server. So we will need to include the redo log volumes as part of the snapshot and clone process.
Shutdown the Database
Set the ORACLE_HOME and ORACLE_SID environment variable for the target database. Then issue the following commands to shutdown the target database.
sqlplus / as sysdba shutdown immediate;
Run the following commands, as root, to unmount the target filesystems.
# umount /oradata/clone/data # umount /oradata/clone/index # umount /oradata/clone/undo # umount /oradata/clone/redo # umount /oradata/clone/redo02
Query the Pure array to see if there are snapshots on the source volumes. Log in to the Pure CLI and perform the following tasks.
purevol list --snap Data.Snap01 5T Data 2016-10-14 15:42:47 EDT 2E7E9632A2A7423100011052 Index.Snap01 2T Index 2016-10-14 15:42:47 EDT 2E7E9632A2A7423100011053 Redo1.Snap01 200G Redo1 2016-10-14 15:42:47 EDT 2E7E9632A2A7423100011055 Redo2.Snap01 200G Redo2 2016-10-14 15:44:13 EDT 2E7E9632A2A7423100011057 Undo.Snap01 300G Undo 2016-10-14 15:42:47 EDT 2E7E9632A2A7423100011054
Remove the snapshots.
purevol destroy Data.Snap01 purevol eradicate Data.Snap01 purevol destroy Index.Snap01 purevol eradicate Index.Snap01 purevol destroy Undo.Snap01 purevol eradicate Undo.Snap01 purevol destroy Redo1.Snap01 purevol eradicate Redo1.Snap01 purevol destroy Redo2.Snap01 purevol eradicate Redo2.Snap01
Take new snapshots of the production volumes. The same snapshot names can be reused since we deleted them in the previous step.
purevol snap --suffix Snap01 Data purevol snap --suffix Snap01 Index purevol snap --suffix Snap01 Undo purevol snap --suffix Snap01 Redo1 purevol snap --suffix Snap01 Redo2
Once the new snapshots are taken of the source volumes, the snapshots need to be copied to the target volumes. Run the following commands to copy the snapshots to the target volumes.
purevol copy --force Data.Snap01 CloneData purevol copy --force Index.Snap01 CloneIndex purevol copy --force Undo.Snap01 CloneUndo purevol copy --force Redo1.Snap01 CloneRedo1 purevol copy --force Redo2.Snap01 CloneRedo2
*Note: The pure array uses SSH as the CLI interface. Therefore, the Pure array can be configured with SSH keys to allow for passwordless SSH. This means that the Pure commands can be run from a script on the database server, thereby fully automating the process.
As root, mount the newly copied filesystems for the target database. Be sure to replace with the appropriate device or mpath name.
# mount /dev/<device> /oradata/clone/data # mount /dev/<device> /oradata/clone/index # mount /dev/<device> /oradata/clone/undo # mount /dev/<device> /oradata/clone/redo # mount /dev/<device> /oradata/clone/redo02
*Important: This process cannot be used with LVM as LVM uses data inside of devices to identify the physical volumes (PVs). If a PV is cloned in this fashion, on the same server as the source PVs, LVM will get confused as to which PV is correct. LVM will see two identical PVs and will potentially corrupt data.
Change File Ownership
If the target database is running under a different Linux user ID, as is common with Oracle EBS databases, then the file ownership will need to be changed for the target files and directories.
chown -R oraclone.dba /oradata/clone
Recreate Database Control File
Since we are renaming the database, the control files in the target database will need to be removed and new control files created with a SQL script.
Delete the existing target control files.
rm -f /oradata/clone/data/control01.dbf rm -f /oradata/clone/index/control02.dbf
Run the SQL script to recreate the control files. An example create control file script is referenced below. The actual datafile names will need to be entered.
STARTUP NOMOUNT CREATE CONTROLFILE SET DATABASE "ORACLONE" RESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 5 MAXDATAFILES 512 MAXINSTANCES 8 MAXLOGHISTORY 14607 LOGFILE GROUP 1 ( '/oradata/clone/redo/log01a.dbf' ) SIZE 512M BLOCKSIZE 512, GROUP 2 ( '/oradata/clone/redo/log02a.dbf' ) SIZE 512M BLOCKSIZE 512, GROUP 3 ( '/oradata/clone/redo/log03a.dbf' ) SIZE 512M BLOCKSIZE 512 DATAFILE '/oradata/clone/data/system01.dbf', '/oradata/clone/data/sysaux01.dbf', '/oradata/clone/index/indx01.dbf', '/oracata/clone/undo/undo01.dbf', '/oradata/clone/data/data01.dbf' CHARACTER SET UTF8 ; -- Other tempfiles may require adjustment. ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata/clone/temp/temp01.dbf' SIZE 25600M REUSE AUTOEXTEND ON NEXT 1024M MAXSIZE 25600M;
*Note: The easiest way to create a control file for a database clone is to run the following statement against the source database.
alter database backup controlfile to trace as ‘/path/cr_ctlf.sql’; then modify the resulting file with all of the target database information.
At this point the database is mounted, is in a crash consistent state, and needs to be recovered with redo. The appropriate redo logs must be passed in to the “recover database” command. Oracle cannot automatically recover the database, as all of the paths have changed, so the redo log file names must be passed in.
sqlplus / as sysdba recover database using backup controlfile; '/oradata/clone/redo/log01a.dbf'
Run the recover commands for the appropriate redo logs in order to bring the target database to a consistent state.
Startup the Database
At this point, the target database can be opened. The “resetlogs” option must be used when opening the target database after the database rename process.
sqlplus / as sysdba alter database open resetlogs;
In this blog I have demonstrated how to instantaneously clone an Oracle database using Pure Storage snapshot and copy commands. This process does not move any data, but instead uses the Pure snapshot technology to make the source data available to a clone. This process has the following advantages:
- Speed – The process is instantaneous since no data is physically copied.
- Automatic – All operations in this process, both Oracle and Pure, are run from the command line and can therefore be fully automated.
- Space – This process is space efficient, as the Pure snapshot and copy processes use linked clone technologies.