General:

Almost wanted to start with once upon a time .. but what good is that kind of start for a blog about ASM compatible.rdbms right? So maybe better stick  to the facts.  On one of the test environments of the billing environment in the past I have set up some 35 databases and registered them all in Oracle Restart 11.2.0.3.  Since this was already several years ago, according to standards back in ASM then only two disk groups existed +DATA and +FRA. All the databases that have been created back then had there archive destination set to +FRA.  This worked okay till recently where  archiving behavior of specific database started changing (high increase of number of archives). That was when it became to set up dedicated diskgroup for each of the databases in that specific scope.

Details:

As part of protocol , dropped a number of disks of the +FRA diskgroup, performed in ASM a rebalance action on that diskgroup after which I was good  to go for my fresh diskgroup. Since all the databases on that server all were 11.2.0.3 this is the way the diskgroup was setup:

CREATE DISKGROUP MYDB01_FRA01 EXTERNAL REDUNDANCY
 DISK '/dev/mapper/asm-redo145p1' name MYDB01_FRA01_0001
ATTRIBUTE 'compatible.asm'='11.2', 'compatible.rdbms'='11.2'
;

Looks perfectly normal right, and all according to the book.  I checked if the diskgroup was mounted (which she was) so next step was the action to work with one of the databases in scope and make sure the archive_destination would be pointing to the new created diskgroup and as part of check after that would perform a logswitch in the database.

## In the alert log of the database this is what was noticed:

ALTER SYSTEM SET log_archive_dest_1='LOCATION=+MYDB01_FRA01' SCOPE=BOTH;
Tue Mar 14 15:59:46 2017
Thread 1 advanced to log sequence 15417 (LGWR switch)
 Current log# 3 seq# 15417 mem# 0: +DATA/MYDB01/onlinelog/group_3.285.765120841
 Current log# 3 seq# 15417 mem# 1: +FRA/MYDB01/onlinelog/group_3.271.765120841
Tue Mar 14 15:59:47 2017
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance MYDB01 - Archival Error
ORA-16038: log 2 sequence# 15416 cannot be archived
ORA-00254: error in archive control string ''
ORA-00312: online log 2 thread 1: '+DATA/MYDB01/onlinelog/group_2.286.765120839'
ORA-00312: online log 2 thread 1: '+FRA/MYDB01/onlinelog/group_2.272.765120841'
ORA-15001: diskgroup "MYDB01_FRA01" does not exist or is not mounted

Hm that was unexpected  because as said I did check the diskgroup to be online in ASM before starting the steps.  So time to look in the Alert log file of ASM.

### In asm logfile
Tue Mar 14 15:59:46 2017
NOTE: Rejecting a request to use grp 'MYDB01_FRA01' from 'MYDB01:MYDB01'.
NOTE: Its version '11.1.0.0.0' is lesser than the minimum required version '11.2.0.0.0' for a database to use this group
Tue Mar 14 16:05:27 2017
NOTE: Rejecting a request to use grp 'MYDB01_FRA01' from 'MYDB01:MYDB01'.
NOTE: Its version '11.1.0.0.0' is lesser than the minimum required version '11.2.0.0.0' for a database to use this group

Clear clue but very much unexpected to be honest because all databases are 11.2.0.3 since I personally set them up.  So one more detail was missing in this puzzle.  Lets look at the specific database:

SQL> show parameter compatible 
 
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
compatible string 11.1.0

For whatever reason in those days when the database was set up the compatible parameter in the database was set to 11.1. Since the database was in a hung status already , time was ticking. Tried to alter the archive_destination again which was not allowed (got error messages). So ready for plan-B:

Dropped diskgroup MYDB01_FRA01 (no archive was written in this group, of course I checked).

## Then in ASM I performed:
 
CREATE DISKGROUP MYDB01_FRA01 EXTERNAL REDUNDANCY
 DISK '/dev/mapper/asm-redo145p1' name MYDB01_FRA01_0001
ATTRIBUTE 'compatible.asm'='11.2', 'compatible.rdbms'='11.1'
;

After that the database was happy (and so was this DBA) and  I had a lesson re-learned. Always expect the unexpected. Or more general, before switching your log_archive_dest to another diskgroup in ASM, make sure the compatible.rdbms  of that diskgroup is set properly.

As always Happy reading,

Mathijs