11g DBCA and DB_RECOVERY_FILE_DEST – bug 6373164
Posted by John Hallas on July 16, 2008
11.1.0.6 OEL 5 RAC
After creating a RAC database in noarchivelog mode using DBCA and then later altering the database to be in archivelog mode I checked that the archivelogs were being written to the +FRA asm diskgroup, which they were. Later I noticed the disk on which the Oracle Home was installed was running out of space and I realised that archive log files were being written to OH/dbs/
The alert log showed the following lines after database startup :-
Using LOG_ARCHIVE_DEST_1 parameter default value as /u00/app/oracle/product/11.1.0/db_2/dbs/arch
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
The Oracle documentation states that if db_recovery_file_dest is set then that will be used. In my case it was set and log_archive_dest_1 was unset.
After searching Metalink I realised that I was hitting bug 6373164 where archive logs are written to a default area of OH/dbs despite db_recover_file_dest being set
The workarounds were to set DB_RECOVERY_FILE_DEST (which was set ) or to set LOG_ARCHIVE_DEST_1.
The relevant system parameters were as follows
System parameters with non-default values:
db_create_file_dest = “+DATA”
db_recovery_file_dest = “+FRA”
db_recovery_file_dest_size= 10G
One bug workaround says use flash recover area, which I tried by unsetting and setting it , still with the same results
SQL> alter system set DB_RECOVERY_FILE_DEST=” scope=spfile sid=’*';
SQL> ALTER SYSTEM SET db_recovery_file_dest=’+FRA’ SCOPE=BOTH SID=’*';
However the way I resolved the issue was to use the location option to log_archive_dest_1
SQL> alter system set LOG_ARCHIVE_DEST_1 = ‘LOCATION=USE_DB_RECOVERY_FILE_DEST’ scope=both sid=’*';
coskan gundogar said
I was looking for this for the last 3 days. I tried every keyword except ASM, when searching on metalink.
Thank you for making my day
Yogesh Bhandarkar said
Another option to resolve this problem is to set log_archive_dest_state_[1..9]=defer.
alter system set log_archive_dest_state_1=defer;
Then crosscheck the new archive log created by querying the v$archived_log view
SQL> select * from v$archived_log where name is not null;