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
First of all, people often fall for this, but high
log file sync
waits do not necessarily mean I/O problem.Second, this could be really troublesome, if you have many physical devices in the ASM diskgroup where your redo logs are, because the extents of your files will be evenly distributed on several disks.
Anyway, you need to find the ASM diskgroup number and file number for your redo logs. For example my redo logs:
Since I use OMF, I can easily recognize the file number, because it is part of the name (258, 257, ...), but you can get this as:
Now I am curious about the first redo logfile (group 1, file 258). In the ASM instance (so not the database instance), I can query as:
So this single redo log file has 51 extents in diskgroup number 1, disk number 0, each extent the size of 1 allocation unit (and the allocation unit I used is 1 MB, and I created a redo log with the size of 50 MB, but that is not relevant here). And that single disk, in my case, is: