This assumes that you've already partitioned the presented disk(s) (and will be using /dev/sd[whatever]N
), and that you're using asmlib
. There will be a kernel module loaded if you are:
[root@oel61 disks]# lsmod | grep oracle
oracleasm 53865 1
[root@oel61 disks]#
As root, scan for candidate disks:
[root@oel61 ~]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]
[root@oel61 ~]#
Then, check to see if the disk has already been "discovered" by ASM:
oracle@oel61 ~]$ asmcmd -p
ASMCMD [+] > lsdsk
Path
/dev/oracleasm/disks/DISK1
/dev/oracleasm/disks/DISK2
/dev/oracleasm/disks/DISK3
ASMCMD [+] >
If not, we need to stamp the device:
[root@oel61 ~]# /etc/init.d/oracleasm createdisk NEWFRA /dev/sdc1
Marking disk "NEWFRA" as an ASM disk: [ OK ]
[root@oel61 ~]#
Scan for candidate disks again, then list - the new device should be there:
[root@oel61 ~]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]
[root@oel61 ~]#
# /etc/init.d/oracleasm listdisks
DISK1
DISK2
DISK3
NEWFRA
#
Or use asmcmd
:
oracle@oel61 ~]$ asmcmd -p
ASMCMD [+] > lsdsk
Path
/dev/oracleasm/disks/DISK1
/dev/oracleasm/disks/DISK2
/dev/oracleasm/disks/DISK3
/dev/oracleasm/disks/NEWFRA
ASMCMD [+] >
Now do a scandisks on the other node and check that everything is as it is on the first node (should be fine if you're using the same /dev device names).
Now the disk is ready to be added to the group.
List the groups:
[oracle@oel61 ~]$ export ORACLE_SID="+ASM"
[oracle@oel61 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Thu Jan 31 15:35:27 2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Automatic Storage Management option
SQL> select name
2 from V$ASM_DISKGROUP;
NAME
------------------------------
DATA
FRA
SQL>
Add disk to the group:
SQL> ALTER DISKGROUP FRA ADD DISK '/dev/oracleasm/disks/NEWFRA';
Best Answer
This can be caused by the
asm_diskgroups
parameter. On older releases (like 11g), this was a typical problem. This parameter was automatically updated, except when a diskgroup was dropped, then its name was not removed from the parameter values.You can check this if you have access to MOS:
Dropped Diskgroup Still Existing in ASM spfile (Doc ID 2241177.1)
BUG:19146721 - DROP DISKGROUP DOES NOT REMOVE THE ASM_DISKGROUP PARAMETER IN RAC
This parameter should not be set manually (unless you fix the incorrect value) and should be left empty. Below is only for demonstration.
Set
asm_diskgroups
for this ASM instance to include a diskgroup that does not exist:Stop + start GI on this node:
Check the parameter again after ASM was started:
And this is from the alert log of this ASM instance: