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;

Unmount Filesystems

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

Pure Snapshots

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

Pure Copy

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.

Mount Filesystems

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.

Recover Database

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;

Conclusion

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.