You have a ASM diskgroup which is about to be full and you need to add new disk to that disk group. Before adding any disk to the disk group you can perform few validation steps to validate whether the candidate disk(s) is/are in good shape and can be accessed from each node (without harming the existing production diskgroups).
Creating the New disk under ASMLib
Create the new ASMLIB disks using the “/etc/init.d/oracleasm createdisk” command as root OS user:
# /etc/init.d/oracleasm createdisk NEW_DISK_01 /dev/mapper/mpathbp1
The name of the disk “NEW_DISK_01” can be of your choice and preferably should denote the purpose of the disk.
Scanning the new disks from all nodes
1. It is important that the new disks are visible from all the nodes in case if RAC environment. If you have ASMLib installed you can use the below commands to verify that the new disks are accessible on each nodes.
Execure as root user
/etc/init.d/oracleasm scandisks
Execute as grid user
$ /etc/init.d/oracleasm listdisks
2. Run the below command as grid user on each of the new disks discovered from the “listdisks” command.
$ /etc/init.d/oracleasm querydisk new_disk_01 $ /etc/init.d/oracleasm querydisk new_disk_02 ....
Make sure all disks are visible from all the nodes in case of RAC configuration.
Using dd to verify OS visibility of disks
1. Confirm the disks are visible (I/O) at OS level (as oracle or grid OS user) from each node:
Syntax
dd if=[raw/character or block partition device in question] of=/dev/null count=100 bs=8192
Example : Raw Disk
$ dd if=/dev/mapper/DATA05 of=/dev/null count=100 bs=8192
Example : ASMLIB device
dd if=/dev/oracleasm/disks/DATA05 of=/dev/null count=100 bs=8192
Using kfed to read disks
1. Verify that kfed can read on the candidate disk(s) at OS level (as oracle or grid OS user) from each node:
Syntax
$ kfed read [raw/character or block partition device in question]
Example : Raw Disk
$ kfed read /dev/mapper/DATA05
Example : ASMLIB device:
$ kfed read /dev/mapper/DATA05
Creating temporary Disk Group
It is always a good practice to create a temporary disk group using the new disk(s) to verify everything works fine without touching the production disk groups. Worst case scenario the test diskgroup would fail, which is fine.
1. To create a new disk group use the below command.
SQL> CREATE DISKGROUP TEST EXTERNAL REDUNDANCY DISK '[YOUR CANDIDATE DISK]';
2. Check if the diskgroup is created and mounted:
SQL> SELECT STATE, NAME FROM V$ASM_DISKGROUP;
3. If it is not mounted, mount it manually using the below command:
SQL> ALTER DISKGROUP TEST MOUNT; SQL> SELECT STATE, NAME FROM V$ASM_DISKGROUP;
Make sure you try mounting the TEST disk group from each ASM instance in case of a RAC configuration.
Dropping the TEST Disk Group
If the previous steps had success and the TEST diskgroup can be successfully mounted (on each ASM instance), then drop the TEST diskgroup as follow.
1. First dismount the TEST disk group from all the ASM instances except for one from where you will be dropping it.
SQL> ALTER DISKGROUP TEST DISMOUNT;
2. Now, drop the TEST disk group from the ASM instance where is is still mounted.
SQL> DROP DISKGROUP TEST;
Add the Disk to desired disk group
Finally, after rigoursly validating the new disks, we can add them to the desired disk group. Add the candidate disk to the disk group using below command.
Syntax:
SQL> ALTER DISKGROUP [my production diskgroup] ADD DISK '[your candidate disk]';
For Example:
SQL> ALTER DISKGROUP PROD_DG ADD DISK NEW_DISK_01
The disk name “NEW_DISK_01” is taken from the command where we created the disk using “oracleasm createdisk” command early in the post.