INS-30502: No ASM disk group found

I’ve been mostly looking busy Informix instances lately so it was nice to have a 12c installation to do at work today. I quickly reacquainted myself of some of my personal rules of Oracle problem-solving:

  1. There is a lot of rubbish posted in online Oracle forums.
  2. Using MOS is generally a better bet.

However, both of these can be lazy ways of solving problems and neither provided the answer to the problem I had. There’s often no substitute for working through a problem yourself.

My 12c instance is a stand-alone one including Grid Infrastructure, ASM and role separation. This means installing Grid Infrastructure as user grid and the database software as user oracle. Having successfully installed Grid Infrastructure and browsed around my working ASM instance using SQL*Plus, I was slightly perturbed to get this error during the installation of the database software when it came to configuring the storage to be used:

INS-30502: No ASM disk group found

In the installActions log I had:

SEVERE: [FATAL] [INS-30502] No ASM disk group found.
CAUSE: There were no disk groups managed by the ASM instance +ASM.
ACTION: Use Automatic Storage Management Configuration Assistant to add disk groups.

But this wasn’t true!

[grid@oraserver ~]$ . oraenv
ORACLE_SID = [grid] ? +ASM
The Oracle base has been set to /u01/app/grid
[grid@oraserver ~]$ sqlplus / as sysasm

SQL*Plus: Release 12.1.0.1.0 Production on Tue Sep 10 11:28:49 2013

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Automatic Storage Management option

SQL> select name, state from v$asm_diskgroup;

NAME STATE
------------------------------ -----------
FRA MOUNTED
DATA MOUNTED

So what was going on? I vageuly remembered that there were some old bugs related to role-separation so I checked the ownership of key files and the group memberships of the oracle and grid users. Everything was ok!

There is a MOS note, 1069517.1, that offers some suggestions but none of the solutions fit, in particular the recommendation to check the permissions on $ORACLE_HOME/bin/oracle. Such a file doesn’t exist yet because I haven’t installed any database software!

Despite this, the problem did smell of a permissions issue. As the installer runs as user oracle, I decided to have a poke around as this user and found this whilst connected to my ASM instance:

oracle@oraserver ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Tue Sep 10 10:47:55 2013

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Automatic Storage Management option

SQL> select * from v$asm_diskgroup;

no rows selected

Is this the same ASM instance as the one above with its two disk groups? Isn’t it only with user_ views or VPD where the output depends on the user?

Here the documentation comes to the rescue:

While an ASM instance is initialized, ASM discovers and examines the contents of all of the disks that are in the paths that you designated with values in the ASM_DISKSTRING initialization parameter. Disk discovery also occurs when you:

  • Run the ALTER DISKGROUP…ADD DISK and ALTER DISKGROUP…RESIZE DISK commands
  • Query the V$ASM_DISKGROUP and V$ASM_DISK views

So the v$asm_diskgroup view actually gets the OS to do something under the covers.

At which point the problem became somewhat obvious:

SQL> show parameter diskstring

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring string /dev/asm/

SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Automatic Storage Management option

On this system, /dev/asm contains the block devices set up in udev. A permission check revealed all:

[oracle@oraserver ~]$ cd /dev/asm
-bash: cd: /dev/asm: Permission denied

The directory could only be viewed by the grid user and members of the asmadmin group. A quick chmod 775 on the directory resolved the problem.

Leave a comment