Shut Down the Database
As we are doing a refresh of the clone database, we need to shut it down.
[root@oracle-vm-prod-003 ~]# srvctl stop database -d lvmdev01Unmount the Diskgroups
Unmount ASM disk groups before the underlying volumes can be overwritten with the latest copy.
ASMCMD> umount LVMDEV01_DATA -f
ASMCMD> umount LVMDEV01_FRA -f
ASMCMD> umount LVMDEV01_REDO -fIf using RAC, the diskgroups need to be unmounted on all nodes. Instead of connecting to each node, it's easier to do it using the following command.
[root@oracle-vm-prod-003 ~]# srvctl stop diskgroup -diskgroup LVMDEV01_DATADelete ASM disks
If using asmlib, delete the oracleasm disks
[root@oracle-vm-prod-003 ~]# oracleasm deletedisk ASM_LVMDEV01_DATA01
Clearing disk header: done
Dropping disk: done
[root@oracle-vm-prod-003 ~]# oracleasm deletedisk ASM_LVMDEV01_FRA01
Clearing disk header: done
Dropping disk: done
[root@oracle-vm-prod-003 ~]# oracleasm deletedisk ASM_LVMDEV01_REDO
Clearing disk header: done
Dropping disk: doneIf the disk group is still mounted when you try to delete the oracleasm disk, you will get an error message like below.>
Clearing disk header: failed
Unable to clear disk "<ASM Disk Name>"Snapshot and Copy Volumes on the FlashArray
Take a snapshot of the source volumes.
SUFFIX=`date +%Y-%m-%d-%H%M%S`
FLASH_ARRAY=10.21.184.113
ssh pureuser@${FLASH_ARRAY} purevol snap --suffix SNAP-$SUFFIX oracle-lvm-prod-002-data-01 oracle-lvm-prod-002-fra-01 oracle-lvm-prod-002-redo-01Copy them to the corresponding target volumes. As we are doing a refresh and the target volumes already exist, the overwrite option needs to be used.
ssh pureuser@${FLASH_ARRAY} purevol copy --overwrite oracle-lvm-prod-002-data-01 oracle-lvm-dev-003-data-01
ssh pureuser@${FLASH_ARRAY} purevol copy --overwrite oracle-lvm-prod-002-fra-01 oracle-lvm-dev-003-fra-01
ssh pureuser@${FLASH_ARRAY} purevol copy --overwrite oracle-lvm-prod-002-redo-01 oracle-lvm-dev-003-redo-01Capture REDO Information From the Source
As we are creating this clone from a crash-consistent snapshot of the source database, there would be some changes in the current redo log file that will required for instance recovery. Run the following SQL on the source database right before or after taking the snapshot. Knowing which log file was current will help us later when we are doing recovery on the target database.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
1 1 7 209715200 512 2 NO CURRENT 2163333 29-JUL-21 1.8447E+19
2 1 5 209715200 512 2 NO INACTIVE 2023319 28-JUL-21 2072663 28-JUL-21
3 1 6 209715200 512 2 NO INACTIVE 2072663 28-JUL-21 2163333 29-JUL-21 Rename ASM Disks
As the target volumes have now been refreshed from production, the ASM disk names need to be updated to correspond to the target names. If using ASMLib, rename the disks of the cloned ASM volumes as shown below.
[root@oracle-vm-prod-003 ~]# oracleasm renamedisk -f /dev/asm-data-01 ASM_LVMDEV01_DATA01
Writing disk header: done
Instantiating disk "ASM_LVMDEV01_DATA01": done
[root@oracle-vm-prod-003 ~]# oracleasm renamedisk -f /dev/asm-fra-01 ASM_LVMDEV01_FRA01
Writing disk header: done
Instantiating disk "ASM_LVMDEV01_FRA01": done
[root@oracle-vm-prod-003 ~]# oracleasm renamedisk -f /dev/asm-redo-01 ASM_LVMDEV01_REDO01
Writing disk header: done
Instantiating disk "ASM_LVMDEV01_REDO01": doneRename ASM Disk Groups
Use renamedg to rename the disk groups
We can first run the command with the check=true option, which will run the command without actually making any changes to the disk group.
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_DATA newdgname=LVMDEV01_DATA verbose=true check=true asm_diskstring='ORCL:*'
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_FRA newdgname=LVMDEV01_FRA verbose=true check=true asm_diskstring='ORCL:*'
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_REDO newdgname=LVMDEV01_REDO verbose=true check=true asm_diskstring='ORCL:*'Here is an example of how the output of this command looks like.
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_DATA newdgname=LVMDEV01_DATA verbose=true check=true asm_diskstring='ORCL:*'
Parameters in effect:
Old DG name : LVMPRD01_DATA
New DG name : LVMDEV01_DATA
Phases :
Phase 1
Phase 2
Discovery str : ORCL:*
Check : TRUE
Clean : TRUE
Raw only : TRUE
renamedg operation: dgname=LVMPRD01_DATA newdgname=LVMDEV01_DATA verbose=true check=true asm_diskstring=ORCL:*
Executing phase 1
Discovering the group
Performing discovery with string:ORCL:*
Identified disk ASM:ASM Library - Generic Linux, version 2.0.12 (KABI_V2):ORCL:ASM_LVMDEV01_DATA01 with disk number:0 and timestamp (33120132 -1415871488)
Checking for hearbeat...
Re-discovering the group
Performing discovery with string:ORCL:*
Identified disk ASM:ASM Library - Generic Linux, version 2.0.12 (KABI_V2):ORCL:ASM_LVMDEV01_DATA01 with disk number:0 and timestamp (33120132 -1415871488)
Checking if the diskgroup is mounted or used by CSS
Checking disk number:0
Generating configuration file..
Completed phase 1
Executing phase 2
Looking for ORCL:ASM_LVMDEV01_DATA01
Leaving the header unchanged
Completed phase 2If the above commands complete successfully, then we can go ahead and run the renamedg command without check=true parameter.
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_DATA newdgname=LVMDEV01_DATA confirm=true verbose=true asm_diskstring='ORCL:*'
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_FRA newdgname=LVMDEV01_FRA verbose=true confirm=true asm_diskstring='ORCL:*'
[grid@oracle-vm-prod-003 ~]$ renamedg dgname=LVMPRD01_REDO newdgname=LVMDEV01_REDO verbose=true confirm=true asm_diskstring='ORCL:*'If using UDEV rules for device persistence instead of ASM, we need to perform the following steps to change the path of the disks.
alter diskgroup <diskgroup> mount restricted;
alter diskgroup <new diskgroup> rename disk 'CURRENT DISKNAME' to 'NEW DISKNAME';We can check that the names of the disk groups have actually changed. At this stage, they would be in the DISMOUNTED state.
ASMCMD> lsdg --discovery
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
DISMOUNTED N 0 0 0 0 0 0 0 0 0 N LVMDEV01_DATA/
DISMOUNTED N 0 0 0 0 0 0 0 0 0 N LVMDEV01_FRA/
DISMOUNTED N 0 0 0 0 0 0 0 0 0 N LVMDEV01_REDO/We can also check that the path names of the disks have changed in the v$asm_disk view.
SQL> select label,path,mount_status from v$asm_disk;
LABEL PATH MOUNT_S
------------------------------- ------------------------------------------------------------ -------
ASM_LVMDEV01_DATA01 ORCL:ASM_LVMDEV01_DATA01 CLOSED
ASM_LVMDEV01_FRA01 ORCL:ASM_LVMDEV01_FRA01 CLOSED
ASM_LVMDEV01_REDO01 ORCL:ASM_LVMDEV01_REDO01 CLOSED�Mount the Disk Groups
SQL> alter diskgroup LVMDEV01_DATA mount;
SQL> alter diskgroup LVMDEV01_FRA mount;
SQL> alter diskgroup LVMDEV01_REDO mount;Startup Nomount Instance
SQL> startup nomount pfile=initlvmdev01.ora
ORACLE instance started.
Total System Global Area 3170890664 bytes
Fixed Size 8901544 bytes
Variable Size 637534208 bytes
Database Buffers 2516582400 bytes
Redo Buffers 7872512 bytesCreate the Control File
We use the create control file script that we created earlier to create a new control file with new disk group names as well as a new db name.
SQL> CREATE CONTROLFILE SET DATABASE "LVMDEV01" RESETLOGS NOARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 292
7 LOGFILE
8 GROUP 1 (
9 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_1.263.1079068693',
10 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_1.266.1079068695'
11 ) SIZE 200M BLOCKSIZE 512,
12 GROUP 2 (
13 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_2.264.1079068693',
14 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_2.267.1079068695'
15 ) SIZE 200M BLOCKSIZE 512,
16 GROUP 3 (
17 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_3.265.1079068693',
18 '+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_3.268.1079068695'
19 ) SIZE 200M BLOCKSIZE 512
20 DATAFILE
21 '+LVMDEV01_DATA/LVMPRD01/DATAFILE/system.257.1079068545',
22 '+LVMDEV01_DATA/LVMPRD01/DATAFILE/sysaux.258.1079068591',
23 '+LVMDEV01_DATA/LVMPRD01/DATAFILE/undotbs1.259.1079068617',
24 '+LVMDEV01_DATA/LVMPRD01/DATAFILE/users.260.1079068617'
25 CHARACTER SET AL32UTF8;
Control file created.
Recover Database
Recover database using backup controlfile until cancel. When prompted, provide the full path to the current redo log file identified in one of the steps earlier.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 2163333 generated at 07/29/2021 03:00:45 needed for thread 1
ORA-00289: suggestion : +LVMDEV01_DATA
ORA-00280: change 2163333 for thread 1 is in sequence #7
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+LVMDEV01_DATA/LVMPRD01/ONLINELOG/group_1.263.1079068693
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.Verify Clone
[oracle@oracle-vm-prod-01 ~]$ ps -ef|grep smon
oracle 13104 13055 0 11:36 pts/9 00:00:00 grep --color=auto smon
grid 17158 1 0 Jul29 ? 00:01:32 asm_smon_+ASM
oracle 22481 1 0 Jul29 ? 00:01:33 ora_smon_lvmdev01
[oracle@oracle-vm-dev-01 ~]$ sqlplus / as sysdba
SQL> select name from v$database;
NAME
---------
LVMDEV01
SQL> select name from v$asm_disk;
NAME
------------------------------
ASM_LVMPRD01_DATA01
ASM_LVMPRD01_FRA01
ASM_LVMPRD01_REDO
SQL> select name from v$asm_diskgroup;
NAME
------------------------------
LVMDEV01_DATA
LVMDEV01_FRA
LVMDEV01_REDO�You might have noticed, the hostname of the cloned VM is still be the same as the source. It was not changed on purpose. That's because the hostname is hard coded in Oracle Grid Infrastructure configuration and changing the hostname will break it and neither ASM nor the database will come up.
To reconfigure Grid Infrastructure configuration, so that ASM comes back up after the hostname change, a few additional steps need to be performed. These steps are discussed in detail in Cloning Oracle Grid Infrastructure for a Standalone Server .