Exadata documentation talks about how to resize an LVM Partitions in compute node for two different scenario -
Obviously anyone will consider to resize the filesystem ONLINE using Option 1. But if the environment came (patched/upgraded) from an older image version (e.g. from <= 22.214.171.124.0, look for imagehistory output) but current running a newer image version, lets say 126.96.36.199.x, 188.8.131.52.x or even greater, though the image is newer but still it might not possible to do the filesystem resize online. This is mainly applicable for X2, X3 (early releases).
Since this environment comes from an older image version, you will see that the filesystem does not have resize_inode options thus it's not possible to resize the filesystem online though it's a new image version currently. In this case, the only possible option is to use the offline method which is a bit critical/complex in terms of the online method.
Below is a series of steps which can be performed to enable the resize_inode option in the filesystem and does not required to use the Option 2.
-- Currently the filesystem does not have 'resize_inode' options -- No output of the below commands, thus we won’t able to resize the filesystem online. # tune2fs -l /dev/mapper/VGExaDb-LVDbSys1 | grep resize_inode # tune2fs -l /dev/mapper/VGExaDb-LVDbSys2 | grep resize_inode
-- Look for the inactive root partitions -- All Exadata compute node should have an inactive root partition which normally used for backup purpose during patching -- In this example: Active root partition is: LVDbSys1 [root@dm01db01 ~]# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 30G 18G 11G 63% / -- Inactive root partition is: LVDbSys2 [root@dm01db01 ~]# lvm lvscan ACTIVE '/dev/VGExaDb/LVDbSys1' [30.00 GiB] inherit << ---- Active ACTIVE '/dev/VGExaDb/LVDbSys2' [30.00 GiB] inherit << ---- Inactive ACTIVE '/dev/VGExaDb/LVDbSwap1' [24.00 GiB] inherit ACTIVE '/dev/VGExaDb/LVDbOra1' [150.00 GiB] inherit ACTIVE '/dev/VGExaDb/LVDbOra2' [450.00 GiB] inherit
Step 1. Remove the existing backup LVM partition Note: The existing backup of the / (root) partition will be lost but we will take another backup shortly # lvremove /dev/VGExaDb/VGExaDb-LVDbSys2
Step 2. Run (Take a backup of / (root) filesystem): /opt/oracle.SupportTools/dbserver_backup.sh
Note: It will create a new VGExaDb-LVDbSys2, if not, then create one manually as below and re-run dbserver_backup.sh once again - # lvcreate -L 30G -n /dev/VGExaDb/VGExaDb-LVDbSys2 # mkfs.ext3 /dev/VGExaDb/VGExaDb-LVDbSys2 -- But dont’t add any label.
Step 3. Once the backup is completed, check the 'resize_inode' option. # tune2fs -l /dev/mapper/VGExaDb-LVDbSys2 | grep resize_inode Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Step 4. Since the current image and backup image is same version, so it's not required to do anything in the /boot partition (e.g. change in grub.conf), but only - -- Remove/Add the label # e2label /dev/VGExaDb/LVDbSys1 "" # e2label /dev/VGExaDb/LVDbSys2 DBSYS OR It's possible to use: dbnodeupdate.sh -r. (Recommend: Rollback using DBNU is well within Oracle Supported Procedure) In this case, dbnodeupdate will rollback to the same image version using the LVDbSys2 partition
Step 5. Restart OS and it should be come up with LVDbSys2
Step 6. Remove & recreate the current backup LVM partition which is /dev/VGExaDb/VGExaDb-LVDbSys1. (Similar to Step 1 & 2 but different partition)
Step 7. Take another backup using dbserver_backup.sh (Similar to Step 1 & 2 but different partition)
Step 8. At this point, we should be able to resize the root LVM partition online using lvextend & resize2fs
For /u01 mount point, it's easier to perform the offline method since it's not required to restart the server, only unmount of the filesystem required.