migratepv questions

[Mag0007]

Lets say I have 3, 36GB SSA drives.

hdisk1:10GB Full
hdisk2:15GB Full
hdisk3:5GB FUll

My questions are:
1) Will I get better performance, if my data is all on 1 drive?
2) If I do a migratepv hdisk1 hdisk2 hdisk3 (move data off hdisk1 and put into hdisk2 and 3), will it split the data evenly or just put the entire 10GB onto hdisk2?
3) Is there a good algorithm I should follow to spread this data across? I prefer keeping everything onto 1 disk.

Also, these aren't raided or mirrored.

TIA

 

[RMGBELGIUM]

No, you will certainly not get better performance with 1 disk if you are talking about constant read-write access ( database OLTP ).Oracle has allways advised to have as many write heads as possible, so small disks.
But : When reading larger streams ( datawarehouse ) , it doesn't matter if you put it on 1 disk.

for question 2 and 3 I can't give you any answer, I haven't done migratepv's from 1 to many disks.

rgds,

R.

 

[p5wizard]

Maybe reorgvg may be a better way to go to distribute LVs evenly among all the PVs of your VG.

You can also "steer" the migratepv by limiting the migrate to a certain logical volume - of course, you would then need to run the command for every LV you want to have moved.

There is (since 5.3 or 5.2 - not sure) also a migratelp command which migrates individual logical partitions (copies) from its current place to a specific PP on a specific PV.

see man pages for all three commands.


HTH,

p5wizard

 

[Mag0007]

thanks everyone for the replies....

running 4.3.3, not sure if that will help.

Seems like reorgvg does not exist on 4.3.3 :-(

 

[p5wizard]

reorgvg has always existed since AIX V3!

# oslevel -r
4330-09
# reorgvg -?
getopt: illegal option -- ?
Usage: reorgvg [-i] VGname [LVname...]
Reorganizes partition allocation within a volume group.

In fact it is a high-level shell script which does some calculations and then calls the low-level command lmigratepp a couple of times...


HTH,

p5wizard

 

[Mag0007]

does the VG have to be varried off for this?

 

[p5wizard]

Nope, all lmigratepp and related commands can be done with VG varied on and LVs open (FS mounted).

I prefer to choose a low-IO period i.e. evening/night because it does strain the disks and IO adapter (be it SCSI, SAN, SSA, whatever).



HTH,

p5wizard

 

[p5wizard]

In case you want to know how LVM does the migration: it's all done with mirrors!

original situation: two LVs on PV1 (full), PV2 empty
  PV1       PV2
-------- --------
LV1-LP1    FREE
LV1-LP2    FREE
LV2-LP1    FREE
LV2-LP2    FREE

migratepv -l LV2 PV1 PV2
creates a mirror copy of each LP of LV2 on PV2, synchronizes the new mirror copy and then removes the original copy from PV1.
  PV1       PV2
-------- --------
LV1-LP1  LV2-LP1-MIRROR
LV1-LP2    FREE
LV2-LP1    FREE
LV2-LP2    FREE

  PV1       PV2
-------- --------
LV1-LP1  LV2-LP1
LV1-LP2    FREE
  FREE     FREE
LV2-LP2    FREE

  PV1       PV2
-------- --------
LV1-LP1  LV2-LP1
LV1-LP2  LV2-LP2-MIRROR
  FREE     FREE
LV2-LP2    FREE

final situation: both PVs have one LV on them and are 50% empty (or full, depending on your level of "optimisticity")
  PV1       PV2
-------- --------
LV1-LP1  LV2-LP1
LV1-LP2  LV2-LP2
  FREE     FREE
  FREE     FREE

Note, in this example, the intra-policy of the LVs (placement of an LV in outer-edge/outer-middle/center/inner-middle/inner-edge of a PV) has not been taken into account, to keep things simple. The commands migratepv or reorgvg WOULD take this into account...

If an already mirrored LV needs to be migrated, then a temporary third mirror copy is used to perform the migration. If an already three-way mirrored LV needs to be migrated, then the third mirror copy is removed and recreated on the destination PV. And yes, LVM is smart enough to not use any stale (unsynchronized) copies when migrating LPs from one PV to another one.


HTH,

p5wizard

 

[costiles]

From my perspective, the value that you want to make sure is correct is the Range of physical volumes should be set to Maximum - then do the re-org. That will distribute the data across all the disks with a physical partition created on each of the disks in roundrobin fashion until all pps are distrbuted. This is a software striping. The outer edge of the disk is the fastest access point as the write heads no longer travel back to the center after each read or write - and the disk can access more data with less turns on the outer edge. So I would go into the smit menu and change the logical volume characteristics to Position on physical volume to edge and Range of physical volumes to Maximum and then insure that all disks are tagged for inclusion. Then run the reorg. You should do this before mirroring as I believe that doing it while mirrored can create a situation where both copies could be on one disk.This will give you maximum performance. If you mirror - the mirrored copy of the pp will resizde on any disk other than the primary copy. Mirror after re-orging.