Oracle DBA – A lifelong learning experience

11g DBCA and DB_RECOVERY_FILE_DEST – bug 6373164

Posted by John Hallas on July 16, 2008 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=’*’;


2 Responses to “11g DBCA and DB_RECOVERY_FILE_DEST – bug 6373164”

  1. 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

  2. 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;

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: