Backing up an Oracle database using FlashCopy is all very simple. The Storwize GUI is really cool, and with
a click of a few buttons we are up and going.
The tricky part is once the backup has completed. The new volumes now have the LVM data structures, which means now they will belong to the original volume group as the source volumes.
Let see how all this happens. In my case, I had my Oracle file on the physical disks hdisk1, hdisk2 , and hdisk2. The physical volumes each belonged to volume groups test_copy1, test_copy2, and test_copy3 respectively. I have created 3 file systems /oradata , /oralog , and /oraarch on these volume groups, to be used by Oracle.
After the FlashCopy Backup/Clone on the volumes complete, we see that the new volumes belong to the volume groups that they are clones of.
The recreatevg command overcomes the problem of duplicated LVM data structures and identifiers caused by a disk duplication process such as FlashCopy. It is used to recreate an AIX Volume Group (VG) on a set of target volumes that are copied from a set of source volumes belonging to a specific VG. The command will allocate new physical volume identifiers (PVIDs) for the member disks and a new Volume Group identifier (VGID) to the Volume Group. The command also provides options to rename the logical volumes with a
prefix you specify, and options to rename labels to specify different mount points for file systems.
a click of a few buttons we are up and going.
The tricky part is once the backup has completed. The new volumes now have the LVM data structures, which means now they will belong to the original volume group as the source volumes.
Let see how all this happens. In my case, I had my Oracle file on the physical disks hdisk1, hdisk2 , and hdisk2. The physical volumes each belonged to volume groups test_copy1, test_copy2, and test_copy3 respectively. I have created 3 file systems /oradata , /oralog , and /oraarch on these volume groups, to be used by Oracle.
After the FlashCopy Backup/Clone on the volumes complete, we see that the new volumes belong to the volume groups that they are clones of.
svp18> lspv hdisk0 00f65d52a5abd459 rootvg active hdisk2 00f65d5108ffefb6 test_copy2 hdisk3 00f65d51bfba4e2e test_copy3 hdisk4 00f65d51c465f8eb metro hdisk5 00f65d52ce125f70 swap active hdisk1 00f65d5108ff9043 test_copy1 hdisk6 00f65d51c465f8eb metro hdisk7 00f65d5108ff9043 test_copy1 hdisk8 00f65d5108ffefb6 test_copy2 hdisk9 00f65d51bfba4e2e test_copy3 isvp18>
The recreatevg command overcomes the problem of duplicated LVM data structures and identifiers caused by a disk duplication process such as FlashCopy. It is used to recreate an AIX Volume Group (VG) on a set of target volumes that are copied from a set of source volumes belonging to a specific VG. The command will allocate new physical volume identifiers (PVIDs) for the member disks and a new Volume Group identifier (VGID) to the Volume Group. The command also provides options to rename the logical volumes with a
prefix you specify, and options to rename labels to specify different mount points for file systems.
isvp18> varyoffvg test_cp1 isvp18> varyoffvg test_cp2 isvp18> varyoffvg test_cp3 isvp18> lspv hdisk0 00f65d52a5abd459 rootvg active hdisk2 00f65d5108ffefb6 test_cp2 hdisk3 00f65d51bfba4e2e test_cp3 hdisk4 00f65d51c465f8eb metro hdisk5 00f65d52ce125f70 swap active hdisk1 00f65d5108ff9043 test_cp1 hdisk6 00f65d51c465f8eb metro hdisk7 00f65d5108ff9043 test_cp1 hdisk8 00f65d5108ffefb6 test_cp2 hdisk9 00f65d51bfba4e2e test_cp3 isvp18> chdev -l hdisk7 -a pv=clear hdisk7 changed isvp18> chdev -l hdisk8 -a pv=clear hdisk8 changed isvp18> chdev -l hdisk9 -a pv=clear hdisk9 changed isvp18> lspv hdisk0 00f65d52a5abd459 rootvg active hdisk2 00f65d5108ffefb6 test_cp2 hdisk3 00f65d51bfba4e2e test_cp3 hdisk4 00f65d51c465f8eb metro hdisk5 00f65d52ce125f70 swap active hdisk1 00f65d5108ff9043 test_cp1 hdisk6 00f65d51c465f8eb metro hdisk7 none None hdisk8 none None hdisk9 none None isvp18> isvp18> recreatevg -y fc_test_cp1 -L /backup -Y bkup hdisk7 fc_test_cp1 isvp18> isvp18> recreatevg -y fc_test_cp2 -L /backup -Y bkup hdisk8 fc_test_cp2 isvp18> recreatevg -y fc_test_cp3 -L /backup -Y bkup hdisk9 isvp18> lspv hdisk0 00f65d52a5abd459 rootvg active hdisk2 00f65d5108ffefb6 test_cp2 active hdisk3 00f65d51bfba4e2e test_cp3 active hdisk4 00f65d51c465f8eb metro hdisk5 00f65d52ce125f70 swap active hdisk1 00f65d5108ff9043 test_cp1 active hdisk6 00f65d5226de2253 fc_metro active hdisk7 00f65d5226bdf18a fc_test_cp1 active hdisk8 00f65d5226c876f6 fc_test_cp2 active hdisk9 00f65d5226ca8c57 fc_test_cp3 active In /etc/filesystems: /backup/oralog: dev = /dev/bkuplv02 vfs = jfs log = /dev/bkuploglv02 mount = true check = false options = rw account = false /backup/oraarch: dev = /dev/bkuplv03 vfs = jfs log = /dev/bkuploglv03 mount = true check = false options = rw account = false /backup/oradata: dev = /dev/bkuplv01 vfs = jfs log = /dev/bkuploglv00 mount = true check = false options = rw account = false isvp18> mount /backup/oradata isvp18> mount /backup/oralog isvp18> mount /backup/oraarch isvp18> isvp18> ln -s /backup/oradata /oradata isvp18> ln -s /backup/oralog /oralog isvp18> ln -s /backup/oraarch /oraarch isvp18> ls -l /oradata lrwxrwxrwx 1 root system 15 Feb 14 23:25 /oradata -> /backup/oradata isvp18> su - sqlplus 3004-500 User "sqlplus" does not exist. isvp18> su - oracle $ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 14 23:26:52 2011 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to an idle instance. SQL> startup; ORACLE instance started. Total System Global Area 1.0289E+10 bytes Fixed Size 2215712 bytes Variable Size 5268046048 bytes Database Buffers 4999610368 bytes Redo Buffers 18743296 bytes Database mounted. Database opened. SQL> The database is now accessible for test, backup, or other development purposes. It is important to note that while the clone is accessing the remote copy replicas, it will not be updated with the latest updates happening to the Metro or Global mirror target volumes.
No comments:
Post a Comment