2 Replies Latest reply on Feb 8, 2013 12:24 AM by mseberg

    RMAN & archive logs (race condition) ?

      Hello there!

      I have not found this in documentation so I´m asking here:

      Let´s have primary and physical standby 11g database managed by Data Guard (not Active). On primary RMAN has retention policy configured to NONE, on standby to APPLIED ON STANDBY.

      And now:

      1.) Standby goes down
      2.) New archive logs are created on primary
      3.) Backup of archive logs on primary
      4.) RMAN DELETE OBSOLETE on primary
      5.) Standby goes up

      As I understand the documentation, it would delete also archive logs which were not transfered to standby because they were backed up.
      I cannot set RMAN policy on primary to APPLIED ON STANDBY as it requires archive log dest. to be MANDATORY which would cause primary database unavailable in case of standby going down.
      And I cannot set RMAN policy to APPLIED ON STANDBY on primary and to NONE on standby, because in case of RMAN backup and DELETE OBSOLETE on standby it would be the same problem - deleted archive logs not yet applied on standby.....

      Is there any easy automated solution to avoid this? (Standby downtime may be between a few seconds to several days.)

      (Initially I thought that APPLIED ON STANDBY means just that RMAN asks standby if the log has been already applied and only in case of positive answer it deletes the log and skips it otherwise, but that´s obviously not the case :-( (see MANDATORY requirement on primary))
        • 1. Re: RMAN & archive logs (race condition) ?
          You can create sql script and call it before "delete obsolete". The script will query v$archived_log and find all logs that were not sent to standby. For all logs it will generate OS command to copy the log to some location. For example :

          spool save_logs.sql

          select 'cp '||name||' to /backup_dir' from v$archived_log where dest_id=1 and not exists (...

          1 person found this helpful
          • 2. Re: RMAN & archive logs (race condition) ?

            This is not true or it does not have to be true :
            I cannot set RMAN policy on primary to APPLIED ON STANDBY as it requires archive log dest. to be MANDATORY which would cause primary database unavailable in case of standby going down.
            Unless there's a great business reason I would always set this :


            If the business says you cannot lose data, but does not provide you the resources for this requirement than you are in situation where you cannot succeed. At some point you have to push back.

            I believe you are talking about "Protection mode". These are two very different things.

            Can you post your Protection mode?


            Mihael is correct, you can use a script to remove/move archive. But it reinvents the wheel. If you have space for Archive let Oracle manage it. If you use a script to move it you will need another to remove it and still another to move it back if you need it. Oracle already handles these things so all you end up doing is making the job harder.

            If you have APPLIED ON STANDBY set RMAN will bark when you try to delete Archive not yet applied.


            OK, I think I understand your question better, you are saying " MANDATORY" will shutdown the Primary if redo cannot be written. I guess that could happen. I would not set a system like this if I could avoid it.

            Chapter 15 of Data Guard Concepts and Administration 11g Release 2 (11.2) E10700-02 has a good "Mandatory" section.

            Unless you have a good business reason set it to "Optional" ( default )

            If you are saying "MANDATORY is requirement on primary" it is not. Keep it simple. Use FRA and RMAN to manage your archive.


            1. Why is MANDATORY a requirement on the Primary? Is this a business requirement? Why can't you have a third DEST_ID for Archive to handle this?
            2. Why do you need to delete archive so fast? Do you have a space limit? If yes why can you not add more disk?
            3. What is wrong with the Standby site that you are so concerned about the Standby going down? Do you have network issues?
            4. Why use DELETE OBSOLETE without a retention policy?

            Best Regards


            Edited by: mseberg on Feb 7, 2013 12:26 PM
            1 person found this helpful