We're here to help!

Understanding AMM Archive Log Deletion "policies"

Follow
Problem Description

If a system  is experiencing some load and disk space conditions and we need to delete archive logs from both the production server and standby server as soon as possible after they have been processed by Dbvisit Standby.

If we  plan to configure AMM to delete logs once the free space percentage goes below a configured threshold (on both systems), but how can we  make sure that when this occurs, it actually won't delete logs until they have been transferred and/or applied.

Solution

The Document is applicable only for Version 6.0

On the primary server the archive logs will not be eligible for delete unless Dbvisit Standby has a record of them being successfully transferred to the DR server IF the AMM_CHECK_TRANSFERRED parameter in your DDC is set to Y:

https://dbvisit.atlassian.net/wiki/display/dbdc/Advanced+Settings

So, as you can see, it is possible to override this default action, so you just need to double check your settings for this. It is also possible to enforce checks to make sure that archive logs have been backed up by RMAN a certain number of times before deleting, which is also something to be aware of.

As far as the AMM process goes on the DR side, it does not perform a check to ensure that a log file has been applied, before considering it eligible for deletion. So if your AMM parameters are set too aggressively then it is possible that you could inadvertently delete a log file which has not yet been applied. One thing worth mentioning here is that there are changes to this behaviour which are to be included in version 7 of Dbvisit Standby, which is not too far away. So, in that version a check will be performed to make sure that the log file on the DR server has actually been applied before deleting it.

Mike Donovan September 03, 2013 12:17

Have more questions? Submit a request

Comments