首页 » ORACLE » RMAN-08137: WARNING archived log not deleted, needed for standby or upstream capture process

RMAN-08137: WARNING archived log not deleted, needed for standby or upstream capture process

an Friends have talked about this issue today,they used oracle dataguard on the DB host ,and oracle DB version was 11G,then they won’t used for standby db, and re-install OS on the standby db host, When he tried deleting archivelog manually with RMAN on primary db host, he got following warning:

“归档日志未删除, 因为备用或上游捕获进程需要它”

Temporary solution to remove archive log

1. Removed archive log from filesystem using OS commands
2. Performed RMAN crosscheck

Other alternative was to remove archive log using force option
delete noprompt force archivelog al completed before ‘’;

Displaying the Log Files That Will Never Be Needed by Any Capture Process:
SELECT * FROM DBA_LOGMNR_PURGED_LOG;

select capture_name, status, captured_scn, applied_scn, capture_type from dba_capture;

if some recode in dba_capture,And make sure it can be deleted,we can drop it use dbms_capture_adm package e.g.execdbms_capture_adm.drop_capture(capture_name =>’xxxxx’);

or

if capture_name like ‘OGG$%’,related to Golden Gate!! This database use to have GG environment, but it was not in use.

use ggsci Utility Deleting the extract,Deleting the extract was not enough. Need to unregister it as well(need dblogin)
then Verified the DBA_CAPTURE view is empty.

After some reading, found that GG 11 will prevent rman from deleting archivelog that hasn’t been mined. RMAN checks min_required_capture_change# in v$database, which is populated every 6 hrs based on dba_capture. Even after extract is stopped, entry is still in dba_capture & RMAN won’t allow archivelog delete.

I read MOS’ notes
Check this note also Archive Log not Getting Deleted Using Rman With Rman-08137 [ID 964522.1]

Check configure auto deletion
Configure RMAN to purge archivelogs after applied on standby [ID 728053.1]

eg.
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;
delete archivelog until time ‘sysdate -1’ backed up 1 times to device type sbt;
CONFIGURE ARCHIVELOG DELETION POLICY CLEAR;

RMAN-08137 When deleting archivelogs even when Streams CAPTURE does not require them [ID 1079953.1]
Symptoms
Applies To:11gR1-11gR2
RMAN is unable to delete archive logs from database even though they are not needed by CAPTURE process anymore.
Changes

Cause
In 11g, RMAN looks at MIN_REQUIRED_CAPTURE_CHANGE# in v$database and not at DBA_CAPTURE. By default this value is updated every 6 hours. So by default the value in v$database

will be six hours behind the current value.

Solution
Since changing frequency of update to MIN_REQUIRED_CAPTURE_CHANGE# in v$database can not be controlled, following workaround can be used:

Archive log which are not needed by capture process can be deleted using:
delete noprompt force archivelog all completed before ‘sysdate-10/1440’;

extend read

we want to keep 24 hours of arch logs on disk and came up with the following ideas with pros and cons.
they are just thoughts now, but I'm open to suggestions.
 1.) use this run block or something similar run
{
   BACKUP ARCHIVELOG ALL not backed up 1 times; #or 2 times.
   DELETE ARCHIVELOG ALL COMPLETED BEFORE 'TRUNC(SYSDATE-1)';
 } 

pros: kind of does what we want. if the backup fails the delete command won't be executed. if it's a separate command, it will execute regardless of the previous command.
cons: if the standby is down for more than 24 hours, the logs will be deleted and have to be restored from tape to sync it up.
2.) use
 backup archivelog all until time "trunc(systdate-1)" not backed up 1 times delete input;

pros: only backups the logs once and deletes them. won't delete them if the standby crashes. you get the error above.
cons: this will always have 24 hours of logs on the disk that have not been backed up.

3.) backup the standby database instead of the primary. 

pros: doesn't impact production, doesn't have to worry about the delete problem because they would have to be applied to the standby first.
cons: diligent about monitoring the standby to keep it in sync. if the standby is in a remote site, getting the logs to the primary might be an issue.

reference oraclehandson‘s blog

打赏

目前这篇文章有1条评论(Rss)评论关闭。

  1. remy Hair | #1
    2012-10-28 at 11:42

    Thank you a bunch for sharing this with all folks you actually know what you are speaking approximately! Bookmarked. Kindly additionally visit my website =). We could have a hyperlink exchange arrangement among us!