I am convinced that you were struck by the situation in which a raw disk used by an Oracle database (ASM and cluster) was filled and those in the database requested a disk expansion or the addition of a new LUN (raw disk). In such situations it is recommended to add a new raw disk and NOT to extend an existing disk.
First you have to add the disk from Storage (here is the part of the Storage team - if you don't have one then you have to add it) and in Linux OS RedHat (suppose you use Multipath) you have to run the following commands to "rediscover" the newly added LUN:
echo "- - -"> / sys / class / scsi_host / host0 / scan echo "- - -"> / sys / class / scsi_host / host1 / scan echo "- - -"> / sys / class / scsi_host / host2 / scan echo "- - -"> / sys / class / scsi_host / host3 / scan echo "- - -"> / sys / class / scsi_host / host4 / scan
(here it depends on how many scsi_hosts you have)
- see in dmsg if something appears with "new SCSI device discovered"
- after scanning the SCSI hosts you can rename the name of your scanned LUN and automatically added by multipath in the file ( /var/lib/multipath/bindings or /etc/multipath/bindins
)
After scanning the raw disk must be added /etc/oracleasmas follows.
- we create a file in /etc/udev/rules.d/new_raw_disk10.rules
- we add:
ACTION == "add | change", ENV {DM_UUID} == "mpath-360050768018086e558000000000004a5", SYMLINK + = "oracleasm / data09", GROUP = "oinstall", OWNER = "oracle", MODE = "0660"
* where "mpath-360050768018086e558000000000004a5
" represents my WWN and the name in the bindings file above.
** where "oracleasm / data09" shows the path and name of my new raw disk.
After adding the new rules we run:
udevadm control --reload-rules && udevadm trigger --type = devices --action = change
That would be all ...