<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Clearing invalid PEs on physical volume(s) in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223040#M630082</link>
    <description>Hello, everybody.&lt;BR /&gt; &lt;BR /&gt;This morning, an external consulting was seeting up Oracle running over raw devices on HPUX 11i and has made two great mistakes:&lt;BR /&gt; &lt;BR /&gt;* 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;&lt;BR /&gt; &lt;BR /&gt;* 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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;My question: is there any way to clear up this mess without a vgreduce/vgremove of vgora01?&lt;BR /&gt; &lt;BR /&gt;TIA,&lt;BR /&gt;Paulo Fessel</description>
    <pubDate>Thu, 18 Mar 2004 13:06:19 GMT</pubDate>
    <dc:creator>Paulo A G Fessel</dc:creator>
    <dc:date>2004-03-18T13:06:19Z</dc:date>
    <item>
      <title>Clearing invalid PEs on physical volume(s)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223040#M630082</link>
      <description>Hello, everybody.&lt;BR /&gt; &lt;BR /&gt;This morning, an external consulting was seeting up Oracle running over raw devices on HPUX 11i and has made two great mistakes:&lt;BR /&gt; &lt;BR /&gt;* 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;&lt;BR /&gt; &lt;BR /&gt;* 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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;My question: is there any way to clear up this mess without a vgreduce/vgremove of vgora01?&lt;BR /&gt; &lt;BR /&gt;TIA,&lt;BR /&gt;Paulo Fessel</description>
      <pubDate>Thu, 18 Mar 2004 13:06:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223040#M630082</guid>
      <dc:creator>Paulo A G Fessel</dc:creator>
      <dc:date>2004-03-18T13:06:19Z</dc:date>
    </item>
    <item>
      <title>Re: Clearing invalid PEs on physical volume(s)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223041#M630083</link>
      <description>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):&lt;BR /&gt; &lt;BR /&gt;00033 current  ???                                 00507&lt;BR /&gt;00034 current  ???                                 00508&lt;BR /&gt;00035 current  ???                                 00509&lt;BR /&gt;00036 current  ???                                 00510&lt;BR /&gt;00037 current  ???                                 00511&lt;BR /&gt;00038 current  /dev/vgora01/P03_UNDO.dbf           00000&lt;BR /&gt;00039 current  /dev/vgora01/P03_UNDO.dbf           00001&lt;BR /&gt;00040 current  /dev/vgora01/P03_UNDO.dbf           00002&lt;BR /&gt;00041 current  /dev/vgora01/P03_UNDO.dbf           00003&lt;BR /&gt;00042 current  /dev/vgora01/P03_UNDO.dbf           00004&lt;BR /&gt;00043 current  /dev/vgora01/P03_UNDO.dbf           00005&lt;BR /&gt;00044 current  /dev/vgora01/P03_UNDO.dbf           00006&lt;BR /&gt; &lt;BR /&gt;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?&lt;BR /&gt; &lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;All the PV's are visible and this server is attached to an EMC Symmetrix SAN.&lt;BR /&gt; &lt;BR /&gt;TIA&lt;BR /&gt;Paulo Fessel</description>
      <pubDate>Thu, 18 Mar 2004 13:35:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223041#M630083</guid>
      <dc:creator>Paulo A G Fessel</dc:creator>
      <dc:date>2004-03-18T13:35:50Z</dc:date>
    </item>
    <item>
      <title>Re: Clearing invalid PEs on physical volume(s)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223042#M630084</link>
      <description>Paulo,&lt;BR /&gt; &lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;Best regards...&lt;BR /&gt;Dietmar.</description>
      <pubDate>Thu, 18 Mar 2004 14:43:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223042#M630084</guid>
      <dc:creator>Dietmar Konermann</dc:creator>
      <dc:date>2004-03-18T14:43:27Z</dc:date>
    </item>
    <item>
      <title>Re: Clearing invalid PEs on physical volume(s)</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223043#M630085</link>
      <description>The problem is that we haven't detected any gaps on minor device ranges.&lt;BR /&gt; &lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;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.&lt;BR /&gt; &lt;BR /&gt;Thanks still,&lt;BR /&gt;Paulo Fessel</description>
      <pubDate>Thu, 18 Mar 2004 15:07:57 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/clearing-invalid-pes-on-physical-volume-s/m-p/3223043#M630085</guid>
      <dc:creator>Paulo A G Fessel</dc:creator>
      <dc:date>2004-03-18T15:07:57Z</dc:date>
    </item>
  </channel>
</rss>

