the magic couple:ORA-02097 and ORA-01261

Lately i've been rather busy setting up backup and recovery test procedures on a Linux RAC.
It has been kind of an adventure as this is my first attempt to set up a RAC on this OS.
Moreover it was decided to try out all the state-of-the-art features that Oracle has charged version 10R2 with, that is ASM, OMF, block change tracking, flashback recovery area and so forth.

Setting up the flashback recovery area has not been hasslefree, as i've been hitting an annoying problem until i found a metalink note explaining the issue.

I was trying to set DB_RECOVERY_FILE_DEST to '+ARCHLOG/ORCL1' using the following command:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+ARCHLOG/ORCL1'
SCOPE=BOTH SID='*';

But all i was getting was this "self-explanatory" error message:

ORA-02097: parameter cannot be modified because
specified value is invalid
ORA-01261: Parameter db_recovery_file_dest
destination string cannot be
translated

So i looked up both codes in the error message book with little success, the explanation was too generic.

At first i thought i had a problem with the size of the area, but changing DB_RECOVERY_FILE_DEST_SIZE didn't fix the problem.

Then i thought the problem was in the SCOPE=BOTH clause, so i changed it to SCOPE=SPFILE;
This was an extremely bad idea indeed.

This time the ALTER SYSTEM command went through without complaints, but troubles started soon after bouncing the db.

The instances won't come up again and error ORA-01261 was reported when trying to startup a single instance from sqlplus.

So, i ended up with a bad SPFILE on an ASM diskgroup, that you cannot change unless the db is running!
Fortunately i had a good copy of the SPFILE before the last changes (this is a really good practice!), so i could reopen the instance by specifying the PFILE instead.

startup pfile=location_of_a_good_init.ora

Once the instance was up and running, i overwrote the corrupt SPFILE by issuing:

CREATE SPFILE='+DBFILES/spfile.ora'
FROM PFILE=location_of_a_good_init.ora

At this point i bounced the db again and all was back to normal.

So, now i was back to the original problem.
I decided to search metalink for some solution and it was fairly easy to find the real reason of the problem in document ID 329899.1
Under ASM you cannot specify a subfolder for the flash recovery area, you can only specify a diskgroup.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+ARCHLOG'
SCOPE=BOTH SID='*';

and voila', the flashback recovery area was finally set.