Operating System - HP-UX
1848424 Members
4738 Online
104027 Solutions
New Discussion

Re: Clearing invalid PEs on physical volume(s)

 
Paulo A G Fessel
Trusted Contributor

Clearing invalid PEs on physical volume(s)

Hello, everybody.

This morning, an external consulting was seeting up Oracle running over raw devices on HPUX 11i and has made two great mistakes:

* when setting up Oracle datafiles, they've used /dev/vgora01/lvname instead of /dev/vgora01/rlvname. This has nuked the block device and has denied our access to the LV(s), as it created DATAFILES with the name /dev/vgora01/lvname;

* noticing what they done, instead of vgexporting and vgimport vgora01 back and then removing the wrongly sized LV's, they just removed both block and raw devices of VG vgora01 and created new LV's, probably with the same minor numbers of the older LV's.

Thus, I'm stuck with PE's that are in use but in principle cannot be dealocated, as I don't have any LV handle to release these PE's. On top of this, there are PV's that have both these PE's and PE's that are being used by LV's that do exist.

My question: is there any way to clear up this mess without a vgreduce/vgremove of vgora01?

TIA,
Paulo Fessel
L'employé propose, le boss dispose.
3 REPLIES 3
Paulo A G Fessel
Trusted Contributor

Re: Clearing invalid PEs on physical volume(s)

Just to clarify things up, here is part of the output of pvdisplay -v /dev/dsk/c4t0d2 (I don't have access to the server right now):

00033 current ??? 00507
00034 current ??? 00508
00035 current ??? 00509
00036 current ??? 00510
00037 current ??? 00511
00038 current /dev/vgora01/P03_UNDO.dbf 00000
00039 current /dev/vgora01/P03_UNDO.dbf 00001
00040 current /dev/vgora01/P03_UNDO.dbf 00002
00041 current /dev/vgora01/P03_UNDO.dbf 00003
00042 current /dev/vgora01/P03_UNDO.dbf 00004
00043 current /dev/vgora01/P03_UNDO.dbf 00005
00044 current /dev/vgora01/P03_UNDO.dbf 00006

I believe this makes things clearer. So, my question is: how do I release the extents up to extent 00037 in this PV without removing the entire VG?

At first I thought that I could pvmove all the extents of LV's that are in this PV to another, but the documentation of pvmove isn't sufficiently clear to assume that the corrupt extents won't be moved.

All the PV's are visible and this server is attached to an EMC Symmetrix SAN.

TIA
Paulo Fessel
L'employé propose, le boss dispose.
Dietmar Konermann
Honored Contributor

Re: Clearing invalid PEs on physical volume(s)

Paulo,

I dont't believe that the old minor numbers got re-used by LVM. Please have a look in /dev/vgora01 if there are any suspicios gaps in the minor numbers of the device special files that are currently present. Re-create the missing files (raw and block) using mknod. Then look again with pvdisplay... the lvols should show up quite normal. The lvremove command should have no problem to remove the lvols now.

Best regards...
Dietmar.
"Logic is the beginning of wisdom; not the end." -- Spock (Star Trek VI: The Undiscovered Country)
Paulo A G Fessel
Trusted Contributor

Re: Clearing invalid PEs on physical volume(s)

The problem is that we haven't detected any gaps on minor device ranges.

A colleague could bring back the devices with minor 0x010001 and 0x010002 and then lvremove them. However, when we tried to do the same with 0x010003 (which was unallocated), there was no device with this minor.

The next minor (0x010004) was already in use by one of the new LV's. Unfortunately I'm still unable to access the server to look for other gaps.

Thanks still,
Paulo Fessel
L'employé propose, le boss dispose.