RMAN-08137: WARNING: archived log not deleted

 

 

 

RMAN> delete archivelog until time 'sysdate-9';

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=289 device type=DISK
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/paic/z4cs2011/stg/t1nba4tm/oradata/fast_recovery_area/T1CPAT/archivelog/2013_10_11/o1_mf_1_17357_95hpn5j6_.arc thread=1 sequence=17357

....

...

 

metalink-上的解释：

Applies to:

Oracle Database - Enterprise Edition - Version 10.2.0.2 to 11.2.0.2 [Release 10.2 to 11.2]
Information in this document applies to any platform.

Symptoms

***Checked for relevance on 16-Nov-2011***

RMAN returns error when trying to delete archivelog files:
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/ora_arc/icv4/log_545066544_1_9010.arc thread=1 sequence=9010

RMAN log verifies issue showing errors on delete:
RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/ora_arc/icv4/log_545066544_1_9010.arc thread=1 sequence=9010

Cause

Streams configuration in database preventing RMAN from deleting archivelog files.

Results of the following query returns zero rather than null:

select min(required_checkpoint_scn) ,min(source_resetlogs_scn)
  from dba_capture
 where capture_type='LOCAL';

 

This indicates that streams configuration is in place in the database. New in 10.2, RMAN is streams aware, and will NOT delete archivelog files needed by streams. RMAN uses the following to determine if an archivelog file is still needed by streams:

Is next_change > required_checkpoint_scn? If so, RMAN will not allow the archivelog to be deleted.  In the case where required_checkpoint_scn = 0, all archives are still needed by streams.  If required_checkpoint_scn is NULL, RMAN will not want to keep the archivelog files for streams. 

Solution

To implement the solution, please execute the following steps:

1. If streams is not being used, drop the Streams capture process
2. Use workaround for bug 5113357, which is:
    Do not use DELETE INPUT option when backing up logs in a Data Guard environment. Use instead (for example):

rman> backup ARCHIVELOG UNTIL TIME '<date>' not backed up 1 times to device type sbt;
rman> delete ARCHIVELOG UNTIL TIME '<date>' backed up 1 times to device type sbt;

 

 

Applies to:

Oracle Database - Enterprise Edition - Version 9.2.0.1 and later
Information in this document applies to any platform.
***Checked for relevance on 16-Dec-2013***

Symptoms

RMAN command 'backup archivelog all delete input' does not delete archivelogs after they have been backed up and issues a warning instead:

RMAN-08137: WARNING: archive log not deleted as it is still needed
archive log filename=/ora03/oraflsh/RMANCCB/1_3740_580667843.dbf thread=1
sequence=3740

The database is part of  a Data Guard configuration and the backup is being run at the Primary database site.  Atlhough the archivelogs are backed up they are not deleted so the archivelog directory is in danger of filling up - if this happens the database will hang as it will not be able to archive any more logs.

New or 'current' archivelogs are being shipped to the Standby site successfully.

If you query v$archived_log on the primary , you will find at least one archivelog with APPLIED=NO:

 

alter session set nls_date_format='dd-mon-rr hh24:mi:ss';
select recid, dest_id, thread#, sequence#, first_time, completion_time, creator, registrar, archived, applied, deleted, status from v$archived_log where standby_dest='YES' and status='A';

 

Cause

If you check the alert log for Primary and Standby, you will find that archiving for the log sequence for which APPLIED='NO' initially failed. It may be that the log was subsequently shipped and applied at the standby site (so there is no gap) but the corresponding entry in the primary v$archived_log.applied column was not updated to 'YES'.

This warning is raised to prevent premature deletion of a log that RMAN believes has not yet been applied to the standby.  Any archived log for which applied='NO' and all logs that come after,  cannot be deleted using 'delete input' option of the backup command.

Solution

Check that the standby database is uptodate - if not, restart managed recovery and resolve the gap first then query the Primary v$archived_log view again for any log sequences that still have applied='NO'.

If you still have logs with applied='NO' and you are certain that these logs has been applied at standby and there is no 'gap', you need to remove the entries from the rman repository:

a. check that  the physical files still exist on disk and if they do, use an OS command to delete them
b. run crosschek followed by delete expired to remove them from the rman repository

 

RMAN>crosscheck archivelog all;
RMAN>delete expired archivelog all;

 

Once the problematic log(s)  have been removed from the rman repository you can resume normal use of 'delete input' option on  the backup command.

 

 

***Checked for relevance on 08-Mar-2013*** Error: RMAN 8317 (RMAN-08317 RMAN-8317)Text: WARNING: archived log not deleted, needed for standby or upstream capture process---------------------------------------------------------------------------Cause: An archived log that should have been deleted was not as it was required by upstream capture process or Data Guard. The next message identifies the archived log.Action: This is an informational message. The archived log can be deleted after it is no longer needed. See the documentation for Data Guard to alter the set of active Data Guard destinations. See the documentation for Streams to alter the set of active streams.RMAN-08317: WARNING: archived log not deleted, needed for standby or upstream capture processRMAN-8317: WARNING: archived log not deleted, needed for standby or upstream capture process