Hello, we will be using mirrovg to migrate our aix 5.2 tl9 VGs to the new dmx. This works well becauce we can do the mirrorvg while the system is up and running - no outage. We will extendvg with new dmx disks and then mirrorvg from the shark vpaths to the new dmx disks. Finally we will unmirrorvg the old vpaths and finally reducevg them out of the VG. Now the VG sits only on the dmx.
One of the VGs (ora_prd below) is a problem becuse it already maxed at 128 PVs, so we can't extendvg it. 127 of these PVs have no free PPs. The VG is over 2TB. My thought is to take a short outage and manually copy the /u01/data4 file system to the new dmx disks. Once that copy is done modify Oracle to point to the new file system on the dmx and bring the app back up. Since we are not currently using host based stripping I was hoping that would free up several PV's. Once the PVs are freed I can reducevg them out of the VG. This would allow me to extendvg with new larger dmx disks. Once I have enough dmx disks in the VG I can do my normal mirrorvg. Is this the best strategy or should I do something else?
ora_prd:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
ora_prd_app jfs2 230 230 3 open/syncd /u01/app
loglv00 jfs2log 1 1 1 open/syncd N/A
ora_prd_data jfs2 8766 8766 66 open/syncd /u01/data
ora_prd_tmp jfs2 156 156 2 open/syncd /u01/work
ora_prd_data3 jfs2 589 589 5 open/syncd /u03/data3
ora_prd_data2 jfs2 2233 2233 22 open/syncd /u01/data2
ora_prd_redo_lv jfs2 148 148 1 open/syncd /u01/prd_redo
prd_tmp_lv jfs2 222 222 4 open/syncd /u01/prd_tmp
ora_prd_data4 jfs2 4147 4147 32 open/syncd /u01/data4
VOLUME GROUP: ora_prd VG IDENTIFIER: 0025132c00004c00000000fbcc2375cf
VG STATE: active PP SIZE: 128 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 16628 (2128384 megabytes)
MAX LVs: 512 FREE PPs: 136 (17408 megabytes)
LVs: 9 USED PPs: 16492 (2110976 megabytes)
OPEN LVs: 9 QUORUM: 65
TOTAL PVs: 128 VG DESCRIPTORS: 128
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 128 AUTO ON: yes
MAX PPs per PV: 1016 MAX PVs: 128
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable
One of the VGs (ora_prd below) is a problem becuse it already maxed at 128 PVs, so we can't extendvg it. 127 of these PVs have no free PPs. The VG is over 2TB. My thought is to take a short outage and manually copy the /u01/data4 file system to the new dmx disks. Once that copy is done modify Oracle to point to the new file system on the dmx and bring the app back up. Since we are not currently using host based stripping I was hoping that would free up several PV's. Once the PVs are freed I can reducevg them out of the VG. This would allow me to extendvg with new larger dmx disks. Once I have enough dmx disks in the VG I can do my normal mirrorvg. Is this the best strategy or should I do something else?
ora_prd:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
ora_prd_app jfs2 230 230 3 open/syncd /u01/app
loglv00 jfs2log 1 1 1 open/syncd N/A
ora_prd_data jfs2 8766 8766 66 open/syncd /u01/data
ora_prd_tmp jfs2 156 156 2 open/syncd /u01/work
ora_prd_data3 jfs2 589 589 5 open/syncd /u03/data3
ora_prd_data2 jfs2 2233 2233 22 open/syncd /u01/data2
ora_prd_redo_lv jfs2 148 148 1 open/syncd /u01/prd_redo
prd_tmp_lv jfs2 222 222 4 open/syncd /u01/prd_tmp
ora_prd_data4 jfs2 4147 4147 32 open/syncd /u01/data4
VOLUME GROUP: ora_prd VG IDENTIFIER: 0025132c00004c00000000fbcc2375cf
VG STATE: active PP SIZE: 128 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 16628 (2128384 megabytes)
MAX LVs: 512 FREE PPs: 136 (17408 megabytes)
LVs: 9 USED PPs: 16492 (2110976 megabytes)
OPEN LVs: 9 QUORUM: 65
TOTAL PVs: 128 VG DESCRIPTORS: 128
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 128 AUTO ON: yes
MAX PPs per PV: 1016 MAX PVs: 128
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable