Migrate Oracle Database Volumes From the Physical Server to Virtual Machine

Oracle

Audience

Public

Technology Integrations

Oracle

Source Type

Documentation

Whenever we are ready to make the switch, the following sequence of steps needs to be executed.

6a. Shutdown the dummy database on the VM.

6b. Dismount the file system or ASM diskgroups.

6c. Copy the data volumes of the prod running on the physical host to the new prod running on the VM.

We will copy the source volumes to the target with the overwrite option. We will not copy the volumes directly, but first, we will create a snapshot of the source protection group. Navigate (Storage-> Protection Groups) to the protection group oracle-rt-ora01prd-pg. Click on it to go to the details page. On the Protection Group Snapshots, click on the plus icon.

Enter a suffix and a protection group snapshot will get created immediately.

Use the following command to snapshot the protection group from the CLI.

SUFFIX=demo
ssh -l ${FA_USER} ${FA_IP} purepgroup snap --suffix $SUFFIX oracle-rt-ora01prd-pg

Click on the protection group snapshot that just got created. That will open a dialog that shows snapshots of the volumes in the protection group.

Click on the copy icon for each volume snapshot that opens the dialog window shown below. Select the volume group as the container, and provide the name of the target volume. Make sure that the overwrite option is selected.

This step can be scripted as follows.

SUFFIX=demo
VOL_GROUP_NAME=vvol-lnx-rt-vm-ora01prd-1de7f237-vg
PG_NAME=oracle-rt-ora01prd-pg

ssh -l ${FA_USER} ${FA_IP} "purevol list --notitle --csv --snap --filter \"name ='*data*'\" ${PG_NAME}.${SUFFIX}* " | while read line
do
  SNAP=`echo $line | cut -d "," -f1`
  TARG=`echo ${SNAP} | cut -d "." -f3`
  ssh -l ${FA_USER} ${FA_IP} "purevol copy --overwrite $SNAP ${VOL_GROUP_NAME}/$TARG" < /dev/null
done

Copy all the file system or ASM volumes for the database. In this example, to keeps things simple, we have only one ASM disk. We do not copy the volume that contains the grid and database software because we installed it manually from the installation media.

6d. Recall that spfile of the production database was stored in the ASM diskgroup. So we need to update the spfile setting of the dummy database on the VM with the spfile location setting from production.

oracle@orademo1$ srvctl modify database -db ora01prd -spfile +ORA01PRD_DATA/ORA01PRD/PARAMETERFILE/spfile.270.1029181705

If we chose not to create the dummy database, we need to register the database with Oracle Clusterware using the following command.

oracle@orademo1$ srvctl add database -db ora01prd -oraclehome /u01/app/oracle/product/19.0.0/dbhome_1    \
                                     -spfile +ORA01PRD_DATA/ORA01PRD/PARAMETERFILE/spfile.270.1029181705

6e. Start the migrated database on the VM.

oracle@orademo1 $ srvctl start database -db ora01prd

oracle@orademo1 $ ps -ef|grep smon
grid     25916     1  0 02:22 ?        00:00:00 asm_smon_+ASM
oracle   27598     1  0 02:30 ?        00:00:00 ora_smon_ORA01PRD

The actual switch over from physical to virtual server only took just a couple of minutes. No data was physically moved.

In this article, we have seen how quick and easy it is to migrate an Oracle database running on a physical server to a VMware virtual machine using Vols. This use case was for migrating a database from physical to virtual machine. Therefore we did not have to change the SID or the database name, and no changes to the database were needed. For reverse migration, i.e. from virtual to physical, the process will pretty much be the same.

This procedure can be used for other use cases like creating and refreshing secondary environments from production. A few additional steps will need to be performed at the end for things like changing the SID and database name.