Oracle 11g ASM Diskgroup Compatibility

Jun 18, 2008 / By Alex Gorbachev

Tags:

Back in April I was at COLLABORATE 08 and delivered a presentation on 11g — Oracle 11g New Features Out of the Box, including Oracle 11g ASM features. The first ASM slide was about diskgroup compatibility, and I have a bit more to share than I said back then.

Every diskgroup in ASM has two compatibility attributes — compatible.asm and compatible.rdbms. In 10.2, the V$ASM_DISKGROUP view has a couple new columns added — COMPATIBILITY and DATABASE_COMPATIBILITY, but only in 11g did Oracle introduce the concept of diskgroup attributes and the V$ASM_ATTRIBUTE view. Thus, there are two ways to check the diskgroup attributes in 11g:

SQL> col COMPATIBILITY form a10
SQL> col DATABASE_COMPATIBILITY form a10
SQL> col NAME form a20
SQL> select group_number, name, 
compatibility, database_compatibility from v$asm_diskgroup;

GROUP_NUMBER NAME                 COMPATIBIL DATABASE_C
------------ -------------------- ---------- ----------
           1 DG1                  11.1.0.0.0 11.1.0.0.0
           2 DG2                  10.1.0.0.0 10.1.0.0.0

SQL> col value form a10
SQL> select group_number, name, value from v$asm_attribute;

GROUP_NUMBER NAME                 VALUE
------------ -------------------- ----------
           1 disk_repair_time     3.6h
           1 au_size              1048576
           1 compatible.asm       11.1.0.0.0
           1 compatible.rdbms     11.1

Note that V$ASM_ATTRIBUTES is filled only when compatible.asm is set to 11.1. What’s important is that you can only change compatibility level upwards; there is no way to reset it back to the lower value. Compatibility attributes can be changed online one at a time:

SQL> alter diskgroup dg2 set attribute 'compatible.asm'='11.1';

Diskgroup altered.

SQL> alter diskgroup dg2 set attribute 'compatible.rdbms'='11.1';

Diskgroup altered.

SQL> select group_number, name, compatibility, database_compatibility from v$asm_diskgroup;

GROUP_NUMBER NAME                 COMPATIBIL DATABASE_C
------------ -------------------- ---------- ----------
           1 DG1                  11.1.0.0.0 11.1.0.0.0
           2 DG2                  11.1.0.0.0 11.1.0.0.0

What are compatibility attributes are useful for? They are very handy for upgrades and migrations when ASM diskgroups need to be available for ASM instances and database instances of different versions. Depending on the migration path, you might need to be able to access some diskgroups from different versions of ASM and different database instances. It might also be useful for transportable tablespaces between 10g and 11g databases.

The compatible.asm diskgroup attribute controls the format of the ASM diskgroup metadata. Only ASM instances with a software version equal to or greater than compatible.asm can mount the diskgroup.

The compatible.rdbms diskgroup attribute determines the format of ASM files themselves. The diskgroup can be accessed by any database instance with a compatible init.ora parameter set equal to or higher than the compatible.rdbms attribute. Note that the compatible.rdbms attribute can be set to 10.2 as well, but I couldn’t see if there were any differences in the feature set except that the compatible.rdbms=10.2 setting requires a database instance with the compatible parameter set to 10.2 or higher. compatible.asm cannot be set below 11.1 except when it’s already 10.1 by default.

The compatible.rdbms attribute can be changed only if compatible.asm is advanced to 11.1. Otherwise, you get the following error message:

SQL> alter diskgroup dg2 set attribute 'compatible.rdbms'='11.1';
alter diskgroup dg2 set attribute 'compatible.rdbms'='11.1'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15242: could not set attribute compatible.rdbms
ORA-15221: ASM operation requires compatible.asm of 11.1.0.0.0 or higher

When creating a new diskgroup, compatibility attributes can be explicitly specified. It is interesting that the default is still 10.1 for both attributes even when the diskgroup is created from an ASM 10g instance and all connected databases are of 11g version. Oracle is conservative here.

During the COLLABORATE presentation, Jeremy Schneider asked me if there is a way to control the default compatibility version and, at that time, I didn’t know how to set the default compatibility to 11.1. Now that I have had a bit of time to look into it, I found couple hidden underscore parameters: _asm_compatibility and _rdbms_compatibility:

SQL> select i.ksppinm, v.ksppstvl from x$ksppi i, x$ksppcv v 
  2  where i.ksppinm in ('_rdbms_compatibility','_asm_compatibility')
  3    and i.indx=v.indx;

KSPPINM                        KSPPSTVL
------------------------------ ----------
_asm_compatibility             10.1
_rdbms_compatibility           10.1

Let’s test.

SQL> alter system set "_asm_compatibility"='11.1' scope=spfile;

System altered.

SQL> alter system set "_rdbms_compatibility"='11.1' scope=spfile;

System altered.

SQL> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started

Total System Global Area  284565504 bytes
Fixed Size                  1299428 bytes
Variable Size             258100252 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted
SQL> select i.ksppinm, v.ksppstvl from x$ksppi i, x$ksppcv v 
  2  where i.ksppinm in ('_rdbms_compatibility','_asm_compatibility')
  3    and i.indx=v.indx;

KSPPINM                        KSPPSTVL
------------------------------ ----------
_asm_compatibility             11.1
_rdbms_compatibility           11.1

SQL> create diskgroup dg3 external redundancy disk '/asm1/dg2-50mb-1.asm';

Diskgroup created.

SQL> select name, compatibility, database_compatibility                     
  2  from v$asm_diskgroup where name='DG3';

NAME                 COMPATIBIL DATABASE_C
-------------------- ---------- ----------
DG3                  11.1.0.0.0 11.1.0.0.0

Now what features are available with different compatibility settings?

Diskgroup attributes

compatible.asm — 11.1
compatible.rdbms — any

Non-default allocation unit size

For AU sizes 1-8 MB, both compatibility attributes can be 10.1.

SQL> select group_number, allocation_unit_size, compatibility, database_compatibility
  2  from v$asm_diskgroup where name='DG4';

GROUP_NUMBER ALLOCATION_UNIT_SIZE COMPATIBIL DATABASE_C
------------ -------------------- ---------- ----------
           3              2097152 10.1.0.0.0 10.1.0.0.0

SQL> select group_number, name, value from v$asm_attribute
  2  where group_number=3;

no rows selected

The absence of the attribute au_size in V$ASM_ATTRIBUTE is confusing, but recall that attributes are displayed only when compatible.asm is set to 11.1.

SQL> select group_number, name, value from v$asm_attribute
  2  where group_number=3;

GROUP_NUMBER NAME                 VALUE
------------ -------------------- --------------------
           3 disk_repair_time     3.6h
           3 au_size              2097152
           3 compatible.asm       11.1.0.0.0
           3 compatible.rdbms     10.1.0.0.0

For AU sizes 16-64 MB both compatibility attributes must be 11.1.

The rest of 11g’s ASM new features — fast mirror resync, variable size extents, preferred read failure groups

Both compatible.asm and compatible.rdbms must be set to 11.1.

It looks like one of our customers is going to production with the new 11g RAC cluster on ASM using some of these new ASM features, so I’m looking forward to see how well it works in real life.

10 Responses to “Oracle 11g ASM Diskgroup Compatibility”

  • Randy Johnson says:

    Nice write up Alex. Thanks for taking the time to work this up. Very helpful.

  • Thanks Randy. With 11.2 there are more compatibility attributes (compatible.advm) and, of course, more values coming into play.

  • Liza says:

    Hi, how to view the physical disks/devices within a partucular disk_group?

    • You can use ASMCMD (lsdsk if the command) but this is available only in 11.2 (I think it’s not there in 11.1 but check it). Or login to ASM instance in SQL*Plus and query v$asm_disk (your probably want to query v$asm_disk_stat if this query will happen often like monitoring – it’s cached info as opposed to v$asm_disk that actually causes ASM to read all disk headers behind the scenes).

  • Rachit says:

    Hello,

    ASM instance in our environment can support databases from version 10.2.0.4 through
    11.2.0.. I want to use all ASM functionality possible for each database, including OCR and
    voting files In the ASM. What is the proper setting for the ASM diskgroup attribute on diskgroups being used by all the instances?

    Need to set compatible.asm to 10.2 and compatible.rdbms to 11.2 ?
    OR
    Need to compatible.asm to 11.2 and compatible.rdbms to 10.2 ?

    • Didn’t notice your comment earlier so by now I assume you can update us on how you set it. Off the top of my head, you needed to set need to compatible.asm to 11.2 and compatible.rdbms to 10.2. However, remember that those attributes are per disk group. It means that if you have some diskgroups used with 11.2 only – you can set compatible.rdbms to 11.2 for them and for 10.2 databases, you can keep those diskgroups with compatible.rdbms=10.2.

  • Horia Berca says:

    Isn’t it the compatible.asm who refers to the settings which control the format of data structures?
    And on the other hand, the RDBMS compatibility relates to the minimum compatible version of the db instance in order for it to mount the disk group.
    Am a little confused here.

    Regards,
    Horia

    • compatible.asm – this regulates what ASM instance can mount the diskgroup. ASM instance version needs to be that or higher.

      compatible.rdbms – this regulates what database instance version can use the diskgroup.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>