Grid Infra – ASM bug on Solaris – slice 2 CANDIDATE

We recently ran into a bug (at least that how I look at it) that is introduced with ASM As of this version, ASM shows slice 2 (the complete disk, starting a cylinder 0 thus inlcuding the VTOC) as an CANDIDATE disk in ASM. In previous versions of ASM (Grid Infra) only slices that started from cylinder 3 (or higher) where shown as CANDIDATE disks in ASM, so you couldn’t accidently select slice 2 to be used for a diskgroup.

In ASM it is possible to add the slice 2 (for example *c0t0d0s2) to an ASM diskgroup while another slice of the same disk, starting at cylinder 3, is already part of the same or even another diskgroup. You can understand what a mess this gives!
Example partition table of solaris disk, where until you would only see partition (slice) 0, starting at cylinder 3 (see MOS note: ASM Does Not Discover Disk on Solaris [ID 368840.1]).

Current partition table (original):
Total disk cylinders available: 13651 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       3 - 13650       49.98GB    (13648/0/0) 104816640
  1 unassigned    wu       0                0         (0/0/0)             0
  2     backup    wu       0 - 13650       49.99GB    (13651/0/0) 104839680
  3 unassigned    wm       0                0         (0/0/0)             0
  4 unassigned    wm       0                0         (0/0/0)             0
  5 unassigned    wm       0                0         (0/0/0)             0
  6 unassigned    wm       0                0         (0/0/0)             0
  7 unassigned    wm       0                0         (0/0/0)             0

ASM ( discovers the following disks now. Take a good look at the disk number of the MEMBER disks and CANDIDATE disks:

SQL> select path,header_status from v$asm_disk order by 1,2;

PATH                                               HEADER_STATUS
-------------------------------------------------- ---------------
/dev/rdsk/c3t60060E8005492800000049280000319Dd0s0  MEMBER
/dev/rdsk/c3t60060E8005492800000049280000319Dd0s2  CANDIDATE
/dev/rdsk/c3t60060E8005492800000049280000319Ed0s0  MEMBER
/dev/rdsk/c3t60060E8005492800000049280000319Ed0s2  CANDIDATE
/dev/rdsk/c3t60060E8005492800000049280000319Fd0s0  MEMBER
/dev/rdsk/c3t60060E8005492800000049280000319Fd0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031A0d0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031A0d0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031A6d0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031A6d0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031A7d0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031A7d0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031A8d0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031A8d0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031A9d0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031A9d0s2  CANDIDATE
/dev/rdsk/c3t60060E800549280000004928000031CBd0s0  MEMBER
/dev/rdsk/c3t60060E800549280000004928000031CBd0s2  CANDIDATE

I have created an SR for this problem, but until then you’ll have the following options:

  1. Set the ASM_DISKSTRING parameter to /dev/rdsk/*s0 (or whatever slice you normally use)
  2. Make sure the user grid does not have any privileges on the /dev/rdsk/*s2 devices.

Update 26-02-2013:
Oracle Support finally came back with an answer and a patch. The most important thing is that they agree that this is actually a bug and created a bug (bug nr. 14577881) for it. Support tells me that the problem is “really” fixed in Oracle 12.2 (when even 12.1 is not even released yet ;-)) but they have created a backport request for it. I just got back that the backport is available as a one-off patch downloadable as patch 14577881 for

This entry was posted in Grid Infrastructure, Uncategorized and tagged , , , , , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Grid Infra – ASM bug on Solaris – slice 2 CANDIDATE

  1. Andres says:

    How come this situation is bug? Opposite situation is bug. ASM should show every slice which ownership is oracle:dba/660. Everyone with root access can modify slice 2 to begin from cyl 3.

    RAC installation guide does not mention that your slice has to begin from cyl 3. If it would be clearly written in installation guide(in same place where disk ownership and permissions are given), same person who could use slice 2 in case
    when asm shows it from slice 0, would make slice 2 begin from cyl 3 with format.

    You cannot overcome DBA stupidity with such a solution.

    Normally in case of RAC and shared storage you will give to whole LUNs under ASM control and in this case it easier to use slice 2 ( you do not have to start to modify the partition table).

    • marcel says:

      Hello Andres,

      Thank you for your comment. Have you read MOS note 368840.1? This note is explaining why ASM didn’t (at least until discover slices
      that started before cylinder 3 (preventing overwriting the VTOC of the LUN). This note tells you that you should not overwrite the VTOC of the
      disk and so you should not use slice 2 (which by default starts at cylinder 0). To prevent ASM from overwriting the VTOC until it didn’t
      show slices that started before cylinder 3 (thus by default slice 2), but for some reason it started doing so when we upgraded to

      Because Oracle recommends you not to touch (read change) slice 2 of a LUN to start at cylinder 3 and Oracle didn’t show this slice until ASM our procedure for new LUN’s is to create a slice 0 that starts at cylinder 3 and ends at the last cylinder. Normally only this slice 0
      would be shown as “CANDIDATE” disks. This procedure is also mentioned in note 368840.1.

      Of course we could/should set oracle:asmadmin privileges only on slice 0 of LUN’s so ASM wouldn’t see slice 2, but this was never necessary until (we are using ASM since 11.1 for all of our databases). Also I agree that a DBA (or someone who manages ASM) should take a good look
      at “CANDIDATE” disks before adding them, but I don’t want to call it stupidity in this case.

      In my opinion this is still a bug because Oracle clearly explains why it didn’t show slices starting at cylinder 0 (default slice 2) in the MOS
      note and in ASM version before made sure you didn’t see these slices to prevent you from making mistakes like this. As you can read at
      the end of my article Oracle actually sees it as a bug now and fixed it in ASM version 12.2, but have backported it to

      BTW: Although something is not mentioned in the installation guide (as the part with the Solaris slices starting at slice 3) this doesn’t mean
      these kind of things don’t exist. I always search MOS for notes about operating system specific bugs/settings and use them besides the installation
      guide. Oracle installation guides tend to be copy/paste documents from earlier releases and don’t always tells you everything.

      Thanks again,


Leave a Reply

Your email address will not be published. Required fields are marked *

Blue Captcha Image