Hi Vipin,
I didn't know it is that urgent to you,
and I didn't find the time today to pop into ITRC.
I just have had a look at your attached sysinfo collector's output which contains all the information (and more than) one would need.
Boy, your server does have quite a few mountpoints where one easily looses orientation.
I do urge you to keep a hardcopy of your fstab's content (or the whole dump of the syscollector) for possible disaster repair.
Thus I may have overlooked something.
So don't take my suggestions for granted and do double check.
Now, you need to 20 GB in /PMOR/db/ORPMORP/data/dat01
From the bdf dump I can see that this filesystem alreay is 20 GB but has only 1.75 GB free space left.
So I assume you wish to increase the filesystem by abt. 18.25 GB to arrive at 20 GB free space?
I'm afraid, from the vgdisplay dump I can see that vg17 (which holds the filesystem) only has 155 PEs of 32 MB left unused.
So you have not quite 5 GB to add.
You could extend the volume by all those remaining 155 PEs by
lvextend -l $((640+155)) /dev/vg17/pmor_data_dat01
and then you would grow the filesystem by
fsadm -F vxfs -b 25440m /PMOR/db/ORPMORP/data/dat01
But as said, this would only increase by 5 GB.
If you need to allocate more you do have to extend the vg17 by one or more PVs which I guess you will claim from a (SAN?) storage subsystem.
After your SAN admin has assigned your server one or more new PVs you would issue an ioscan to identify the new device(s).
ioscan -nfCdisk | more
You will most likely identify the new disks from their missing device special files, or if you know the last instance No. from a prior ioscan you will recognise the new increment.
The you would have to create new device files
(which the system automatically would do on a reboot, but you don't want this)
If you noted the new instance No. you could
insf -e -C disk -I ???
(substitute ??? with the No.)
or you could recreate all special files if you noted the HW path the new disks are attached to
insf -e -H ?/?/?.?.???.?
(again replace the ?)
Then reissue ioscan to verify the special files have been created
ioscan -knfCdisk
Now one would check the size of the new disk
diskinfo /dev/rdsk/c?t?d?
Then create a physical volume
pvcreate /dev/rdsk/c?t?d?
If it belonged to another VG and hasn't been cleared cleanly you would have to use the force switch -f with pvcreate above.
Be extremly careful at this point and better check twice that you refer to the correct disk as the pvcreate would erase all data on the PV (well not really, but it would be a real pain to recover data from an overwritten PV)
Then extend vg17 by the new PV(s)
vgextend /dev/vg17 /dev/dsk/c?t?d?
(note that you use the block device here)
Now a verbose vgdisplay should list the new PV with all its PEs unallocated yet.
vgdisplay -v vg17 | more
Finally you can repeat the lvextend and fsadm as described above.
Apropos, I noticed you have many alternate links.
You would include those to vg17 in the same manner with the vgextend command from above but passing the alternate block device files as argument.
Create their special files also with the insf command as shown above after having identified their instance No. or HW path from an ioscan.
Also it could be necessary for your storage system to change the newly added PVs' timeout .
You would use the pvchange command to this end like
pvchange -t n /dev/dsk/c?t?d?
where n is the timeout in secs.
Ask your SAN admin or refer to the storage system vendor's manual for the required timeout.
HTH
Madness, thy name is system administration
