Trying to get ASM disks under asmlib rather than system

From: Don Seiler <>
Date: Tue, 1 Apr 2008 21:57:45 -0500
Message-ID: <>

Using RDBMS on RHEL4 x86-64. Some of you might recall my earlier thread regarding ASM in which I used asmlib to create disks, but then (foolishly) set asm_diskstring='/dev/oracleasm/disks/*' rather than 'ORCL:*'.

I'd like to be able to correct this now without having to destroy the disk group and disks that exist. The two disks still show up in listdisks:

# /etc/init.d/oracleasm listdisks
VOL02 But in v$asm_disks I have this:

NAME                           LIBRARY
DGROUP1_0000                   System
DGROUP1_0001                   System

I was under the impression that I would be able to change the asm_diskstring parameter to 'ORCL:*' and bounce the ASM instance and have it both see the disks and recognize where they belong. However after bouncing the instance I get this (DGROUP1 is the existing disk group):

ORA-15032: not all alterations performed ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DGROUP1" The alert log had this to say:

Tue Apr 1 21:27:02 2008
ORA-15186: ASMLIB error function = [asm_open], error = [1], mesg =
[Operation not permitted]

Tue Apr 1 21:27:02 2008
ORA-15186: ASMLIB error function = [asm_open], error = [1], mesg =
[Operation not permitted]

Tue Apr 1 21:27:02 2008
ERROR: no PST quorum in group 1: required 2, found 0 Tue Apr 1 21:27:02 2008
NOTE: cache dismounting group 1/0x2381A1FE (DGROUP1) NOTE: dbwr not being msg'd to dismount
ERROR: diskgroup DGROUP1 was not mounted

We're not using any multipathing on these disks, according to the sysadmin.

I'm not going to venture a guess as to what the problem is. Needless to say that I was rushed and careless when setting this disk group up the first time.

FWIW, I was able to fall back to setting asm_diskstring=/dev/oracleasm/disks/VOL* and getting it the disks to mount fine again. This is on a development instance. We're looking to move the other dev instances on this server to ASM too, perhaps we should create a new disk group for those and then drop DGROUP1 and re-use its disks when it comes time to restore that particular instance from a fresher image of production.

Don Seiler
Received on Tue Apr 01 2008 - 21:57:45 CDT

Original text of this message