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 22.214.171.124. 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.
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 126.96.36.199 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 '188.8.131.52.0' is lesser than the minimum required version '184.108.40.206.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 '220.127.116.11.0' is lesser than the minimum required version '18.104.22.168.0' for a database to use this group
Clear clue but very much unexpected to be honest because all databases are 22.214.171.124 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,