Deletion of database file ''' waiting for releasing it by Oracle..

[Former Member]

Hi Guys,

I'm getting a lot of warning/message Deletion of database file ''' waiting for releasing it by Oracle... .

Anyone has any idea how to fix this?

BR0280I BRARCHIVE time stamp: 2011-12-29 06.07.54

BR0641I Deletion of database file 'U:\oracle\GPF\oraarch\GPFARCHARC63445_0734996928.001' waiting for releasing it by Oracle...

BR0280I BRARCHIVE time stamp: 2011-12-29 06.08.54

BR0641I Deletion of database file 'U:\oracle\GPF\oraarch\GPFARCHARC63445_0734996928.001' waiting for releasing it by Oracle...

BR0280I BRARCHIVE time stamp: 2011-12-29 06.09.14

BR0015I Offline redo log file U:\oracle\GPF\oraarch\GPFARCHARC63445_0734996928.001 deleted

BR0280I BRARCHIVE time stamp: 2011-12-29 06.09.14

BR0014I 150 of 217 offline redo log files processed - 14638.743 MB of 21163.045 MB done

BR0204I Percentage done: 69.17%, estimated end time: 8:26

BR0001I ***********************************_______________

BR0280I BRARCHIVE time stamp: 2011-12-29 06.10.14

BR0641I Deletion of database file 'U:\oracle\GPF\oraarch\GPFARCHARC63446_0734996928.001' waiting for releasing it by Oracle...

BR0280I BRARCHIVE time stamp: 2011-12-29 06.11.14

BR0641I Deletion of database file 'U:\oracle\GPF\oraarch\GPFARCHARC63446_0734996928.001' waiting for releasing it by Oracle...

Regards,

Dafi

[stefan_koehler · Accepted solution]

Hello Dafi,

it looks like Oracle (or Windows) still has an open file handler on it.

To verify the exact root cause of this error set BR_TRACE to 15 and execute a brarchive run again.

http://help.sap.com/saphelp_nw04/helpdata/en/e7/4fb2a8ee10294dbb23378a23e84e46/content.htm

Regards

Stefan

[Former Member · Accepted solution]

Hi Stefan,

Thanks for the feedback.

There is a backlog of transferring the offline redo log to the standby database due to high system activity. I noticed the process which hold-up the brarchive deletion process (in primary), which is waiting for the a process in my standby system (maybe a validation due to the SYNC setting for the data guard).

So, I'm thinking to put the setting to ASYNC. Do you think this will help?

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'

LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

Regards,

Dafi

[stefan_koehler · Accepted solution]

Hello Dafi,

you can not save and delete the archive logs on primary site with the BR*Tools as long as they are not transfered to standby - no matter which transport mechanism you are using (LGWR or ARCn).

The various transport mechanisms are explained in the official documentation:

http://docs.oracle.com/cd/B19306_01/server.102/b14239/log_transport.htm#i1268542

With native RMAN there are some possibilities to "overwrite" this archive log gap protection - but i don't know if the BR*Tools having such a logic too.

You can verify the gap with the following view:

http://docs.oracle.com/cd/E11882_01/server.112/e17110/dynviews_1014.htm#I1030009

Regards

Stefan

[Former Member · Accepted solution]

Hi Stefan,

Happy New Year, thanks for the reply.

The definition of ASYN based on your link:

"The ASYNC attribute performs all network I/O asynchronously and control is returned to the executing application or user immediately, without waiting for the network I/O to complete."

So, What is my option? I've suggested to increase the bandwidth between two sites. FYI, the database is not configured to use RMAN.

Regards,

Dafi

[stefan_koehler · Accepted solution]

Hey Dafi,

So, What is my option? 

You are not facing a huge performance impact on your SAP system, because of you are using LGWR ASYNC mode.

But your currently available network bandwidth is too low - so no matter what kind of log transfer mechanism you are using - you will have that situation (Deletion of database file ''' waiting for releasing it by Oracle). The possibility to delete archive logs (with RMAN) which are still needed for DR is not an option - it is just a temporary work around to keep your primary system running.

Your options are pretty limited:

1) Increase your network bandwidth

2) If you are already on Oracle 11g R2 - you can use ACO to compress the redo stream (http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_arch_dest_param.htm#SBYDB4902). If you also switch the tranfer mechanism to ARCn the compression is very high (it is also working with LGWR, but the compression is lower).

I guess you are using the LGWR mode to meet your requirements - so keep that.

Regards

Stefan

[Former Member · Accepted solution]

Hi Stefan,

Sorry to confuse you. My current setting is SYNC.

Setting in my Primary database:

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;

PROTECTION_MODE

MAXIMUM PERFORMANCE

SQL> show parameter log_archive_dest

log_archive_dest_1 string LOCATION=U:\oracle\GPF\oraarch\GPFarch

log_archive_dest_2 string SERVICE=GPF_DR

Edited by: Eida Hanafiah on Jan 3, 2012 1:58 AM

[Former Member · Accepted solution]

Manage to find out what is the program that being putting a lot of activity in the system. So, manage to ask the user to terminate the periodic job.

Regards,

Dafi