Replacing a mirrored 2G database disk

[Haitham Hamad]

I have a D350 running HP 11.0. It has 5 disks (4-2G's and 1-9G) mirrored on a 8-disk external disk array. I need to replace one of the 2G database disk with an 18G and mirror it on the disk array with another 18G. I am trying to do this with the minimal downtime impact. Let's say that the disk is /dev/dsk/c0t1d0 mirrored on /dev/dsk/c1t2d0 and contains userdata.dbf, redo01.log and control01.ctl

Plan A: (Using mirror, replace maindisk)
1- lvreduce -m 0 /dev/dsk/c0t1d0
2-vgreduce /dev/vg01 /dev/dsk/c0t1d0
The DB will now be using the data on the mirror disk.
3- Replace the 2G with the 18G (hot swappable)
4- pvcreate /dev/dsk/c0t1d0
5- vgextend /dev/vg01 dev/dsk/c0t1d0
6- lvextend -m 1 /dev/vg01 /dev/dsk/c0t1d0
Repeat same procedure with /dev/dsk/c1t2d0

PlanB (Conservative plan)
1- shutdown the database.
2- backup the database to tape
3- blow away vg01
4- replace the disks
5- Recreate vg01
6- recover data from tape.

Is PlanA doable and that's why we have mirror in the first place right?. Plan B will have considerable downtime compared to plan A but much safer. Your feedback is highly appreciated.

TIA, Haitham

[James R. Ferguson · Accepted solution]

Hi:

Plan-A looks OK [ except the syntax for 'lvreduce' uses the logical volume, like "/dev/vg01/lvol1" ;-) ]. I would, however, provide yourself some extra insurance, and have a good backup, just-in-case.

...JRF...

[boley janowski]

your plan A idea is the way to go, like you said that is why its being mirrored in the first place. but make sure you have good backups and reguardless. im guessing this is all raw disk space based on the syntax you used. But once you have it all straight your first plan will do it for you.

Good luck

[Peggy Fong]

Hi
Agree that plan A should work. One thing to look into that might be an issue is the maximum PEs per disk. If you're introducing a larger disk into an existing volume group you will get the max PE per disk that currently is assigned to the volume group. Believe you cannot change it on the fly. There were other discussions in the forum regarding this (just search for vgextend). Plan will still work, but you might have a future work item to fix that issue of max PE (unless you already have that parameter set so the 18g disk will be fully available.

Just a thought.

Regards,
Peggy

[James R. Ferguson]

Hi again:

Peggy makes an important point:

The 'max-pe' parameter of 'vgcreate' specifies the maximum number of physical extents that can be allocated to *any* physical disk in a volume group. The range varies from 1 to 65,535, but the value is *fixed* at 'vgcreate' time to be 1016 or the larger of the largest physical volume size used during the 'vgcreate' process. Once set, 'max-pe' (and/or 'max-pv') can't be changed. Hence, adding an 18GB physical disk to a volume group originally created with a 4GB one will "waste" over 9GB of the 18GB disk.

Regards!

...JRF...

[boley janowski]

peggy,

that is an excellent point, if you didnot set up the vg01 to handle the larger disk when you created with smaller ones you will have problems. you will need to create a new volume group and then you can exicute a vxdump to copy the data back over, another option if you need to maintain the vg01 as the device, you will need to vgexport/vgimport to a new location, the create your vg01 with the new disk or use the vgcreate with the -s arguement.

good luck

[Haitham Hamad]

Thanks everyone. Thanks peggy for reminding me about the max pe limitation.
Looks like plan B will be the winner since my max PE for vg01 is 1016.

[MANOJ SRIVASTAVA]

Hi Haitham

I think the second one ( conservative plan ) is a better one bcoz of two factors :

1.If you have an option of blowing of vg01 then it is better to restart from scratch.

2. More flexibilty to audit other vg01 volumes which you couldnt blow away in case you were just extending.

Manoj Srivastava

[boley janowski]

Haitham,

Yeah your right, it looks like the B option, a coworker just pointed out that vxdump will most likely not work on raw file systems (man vxdump specifies vxfs file systems) just thought I would let you know.