Oops, that is not good 🙁
/dev/mapper/database_vg-db_vol 690G 655G 12K 100% <the SHADOW database filesystem>
This happened at 4am. What can you do in case that this happens to you? Praying is always a solution. The better solution is checking your free physical space.
[root@mymachine ~]# pvs
Found duplicate PV fFza0t96dLLdVGnklCVRvIFacmJ1Kd4I: using /dev/sdc not /dev/sdq
PV VG Fmt Attr PSize PFree
/dev/emcpowera audit_vg lvm2 a-- 2.00t 548.00g
/dev/emcpowerb logs_vg lvm2 a-- 500.00g 1020.00m
/dev/emcpowerc database_vg lvm2 a-- 1.46t 600.00g
/dev/sda3 vg_scloshad2 lvm2 a-- 127.93g 0
Phew 600GB available. So let’s see how the logical drive can be extended by 200GB.
[root@mymachine ~]# lvextend -L +200G /dev/mapper/database_vg-db_vol /dev/emcpowerc
Found duplicate PV fFza0t96dLLdVGnklCVRvIFacmJ1Kd4I: using /dev/sdc not /dev/sdq
Extending logical volume db_vol to 900.00 GiB
Logical volume db_vol successfully resized
That was quick. Now we have to resize the filesystem and we can do this while the database is still up and running 🙂
[root@mymachine ~]# resize2fs /dev/mapper/database_vg-db_vol
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/database_vg-db_vol is mounted on /trak/sclo/SHADOW/db/data; on-line resizing required
old desc_blocks = 44, new_desc_blocks = 57
Performing an on-line resize of /dev/mapper/database_vg-db_vol to 235929600 (4k) blocks.
The filesystem on /dev/mapper/database_vg-db_vol is now 235929600 blocks long.
…. 5 minutes later.
/dev/mapper/database_vg-db_vol 886G 655G 187G 78% /trak/sclo/SHADOW/db/data
It is quite possible that you already used up all the physical space for your virtual drives. In that case you can easily add more physical disks or LUNs to the disk group in using the ‘vgextend’ command. E.g. vgextend database_vg /dev/emcpowerd
