Scenario: mpath0p1 – 1 TB SATA disk
mpath1 – 3 TB SAN LUN
pvcreate the new (3TB FC) disk
Now, add this disk into the oraproddb Volume Group
# vgextend oraproddb /dev/mapper/mpath1
we need the physical extends from the new disk to be “available physical extents” in order to perform the migration.Start migration from the /dev/mapper/mpath0p1 (2.0TB SATA disk) PV to the new /dev/mapper/mpath1 (3TB FC disk) PV.
# pvmove -b /dev/mapper/mpath0p1 /dev/mapper/mpath1
For 2.0TB SATA to 3TB FC, on different filers and different shelves, this took couple of hours to complete.
Make sure to check the migration progress… Take a look in the “Copy%” column for the LV and VG that you’re on.
# lvs -a -o+devices
When the migration is completely finished, you will know because the “Copy%” column will no longer register a value for the LV and VG that you’re working in.
Now, you can safely remove the original PV (2.0TB SATA) from the VG. pvmove has already performed all of the necessary backend changes required to ensure that all of the data is going to the new disk.
# vgreduce oraproddb /dev/mapper/mpath0p1
# pvremove /dev/mapper/mpath0p1
And, lastly, perform the filesystem resize as we already know how to. Without specifying a new size, of course, it instruct the filesystem to consume the entire length of the Logical Volume.
# resize2fs /dev/mapper/oraprod-data
# mount -o remount /dev/mapper/oraprod-data