On an Oracle Exadata Database Machine, the ‘/’ (root) is defaulted to a size of 30Gb, which can easily fill up. Luckily this is just a Logical Volume and there’s normally lots of space available on the Logical Volume Group which is usually untapped.
Extending ‘/’
Identify how much space is used and free on ‘/’ using df:
[root@v1ex1dbadm01 ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 30G 22G 6.2G 79% / [root@v1ex1dbadm01 ~]#
Display the current logical volume configuration using the lvs command:
[root@v1ex1dbadm01 ~]# lvs -o lv_name,lv_path,vg_name,lv_size LV Path VG LSize LVDbOra1 /dev/VGExaDb/LVDbOra1 VGExaDb 200.00g LVDbSwap1 /dev/VGExaDb/LVDbSwap1 VGExaDb 24.00g LVDbSys1 /dev/VGExaDb/LVDbSys1 VGExaDb 30.00g LVDbSys2 /dev/VGExaDb/LVDbSys2 VGExaDb 30.00g LVDoNotRemoveOrUse /dev/VGExaDb/LVDoNotRemoveOrUse VGExaDb 1.00g [root@v1ex1dbadm01 ~]#
PLEASE NOTE: On Exadata there are 2 SYS volumes, of which one is active and the other inactive. These are used when patching the compute node, as one is a backup of the current and is used for rollback purposes.
Check the online resize option is available using the tune2fs command:
[root@v1ex1dbadm01 ~]# tune2fs -l /dev/VGExaDb/LVDbSys1 | grep resize_inode Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize [root@v1ex1dbadm01 ~]# tune2fs -l /dev/VGExaDb/LVDbSys2 | grep resize_inode Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize [root@v1ex1dbadm01 ~]#
If not available then the file system needs to be unmounted before resizing. Refer to documentation:
Verify there’s space available in the Logical Volume Group using vgdisplay command:
[root@v1ex1dbadm01 ~]# vgdisplay -s "VGExaDb" 1.63 TiB [285.00 GiB used / 1.36 TiB free] [root@v1ex1dbadm01 ~]#
Finally if there’s enough space, then extend the Logical Volumes using lvextend command:
[root@v1ex1dbadm01 ~]# lvextend -L +70G /dev/VGExaDb/LVDbSys1 Size of logical volume VGExaDb/LVDbSys1 changed from 30.00 GiB (7680 extents) to 100.00 GiB (25600 extents). Logical volume LVDbSys1 successfully resized. [root@v1ex1dbadm01 ~]# [root@v1ex1dbadm01 ~]# lvextend -L +70G /dev/VGExaDb/LVDbSys2 Size of logical volume VGExaDb/LVDbSys2 changed from 30.00 GiB (7680 extents) to 100.00 GiB (25600 extents). Logical volume LVDbSys2 successfully resized. [root@v1ex1dbadm01 ~]#
Followed by a resize of the file system using resize2fs command:
[root@v1ex1dbadm01 ~]# resize2fs /dev/VGExaDb/LVDbSys1 resize2fs 1.43-WIP (20-Jun-2013) Filesystem at /dev/VGExaDb/LVDbSys1 is mounted on /; on-line resizing required old_desc_blocks = 2, new_desc_blocks = 7 Performing an on-line resize of /dev/VGExaDb/LVDbSys1 to 26214400 (4k) blocks. The filesystem on /dev/VGExaDb/LVDbSys1 is now 26214400 blocks long. [root@v1ex1dbadm01 ~]#
The inactive SYS volume may give you errors as shown below:
[root@v1ex1dbadm01 ~]# resize2fs /dev/VGExaDb/LVDbSys2 resize2fs 1.43-WIP (20-Jun-2013) Please run 'e2fsck -f /dev/VGExaDb/LVDbSys2' first. [root@v1ex1dbadm01 ~]#
In which case, you just need to run the command to check the file system for error that may have occurred with journal-ling after unclear shutdown:
[root@v1ex1dbadm01 ~]# e2fsck -f /dev/VGExaDb/LVDbSys2 e2fsck 1.43-WIP (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/VGExaDb/LVDbSys2: 111629/1966080 files (0.1% non-contiguous), 5031185/7864320 blocks [root@v1ex1dbadm01 ~]#
Now re-run the resize of the file system using resize2fs command:
[root@v1ex1dbadm01 ~]# resize2fs /dev/VGExaDb/LVDbSys2 resize2fs 1.43-WIP (20-Jun-2013) Resizing the filesystem on /dev/VGExaDb/LVDbSys2 to 26214400 (4k) blocks. The filesystem on /dev/VGExaDb/LVDbSys2 is now 26214400 blocks long. [root@v1ex1dbadm01 ~]#
You should now see ‘/’ with additional 70Gb less formatting:
[root@v1ex1dbadm01 ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 99G 22G 72G 24% / [root@v1ex1dbadm01 ~]#
Also see the Logical Volumes are now 100Gb from 30Gb:
[root@v1ex1dbadm01 ~]# lvs -o lv_name,lv_path,vg_name,lv_size LV Path VG LSize LVDbOra1 /dev/VGExaDb/LVDbOra1 VGExaDb 200.00g LVDbSwap1 /dev/VGExaDb/LVDbSwap1 VGExaDb 24.00g LVDbSys1 /dev/VGExaDb/LVDbSys1 VGExaDb 100.00g LVDbSys2 /dev/VGExaDb/LVDbSys2 VGExaDb 100.00g LVDoNotRemoveOrUse /dev/VGExaDb/LVDoNotRemoveOrUse VGExaDb 1.00g [root@v1ex1dbadm01 ~]#
Documentation for reference:
Extending the root LVM Partition on Systems Running Oracle Exadata System Software Release 11.2.3.2.1 or Later
Related Post:
Extending a Non-root LVM Partition on Exadata
If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.
Thanks
Zed DBA (Zahid Anwar)
Pingback: Extending a Non-root LVM Partition on Exadata | Zed DBA's Oracle Blog
Thanks a lot, it helped us hard time…!
LikeLike
You’re welcome 🙂
LikeLike