RE: RMAN/DG - delete *ONLY* archive logs "already shipped to thestandby DataGuard database"?

  • From: "Joel Garry" <joelgarry@xxxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 11 Jan 2005 15:50:32 -0800

Marquez, Chris wrote:

>I agree, best to delete after the whole process is complete...applied
>the standby, 
>but my goal is; a good backup, an empty (primary) archive log dir and
>not "create" a gap while doing these two.

What has bothered me in the older versions is that I wasn't convinced
there was a good atomic backup, since Oracle didn't seem to get the
alter system archive log current straight, and creating the standby db
often seemed arbitrary as to which logs it requires.  So I came to think
that emptying the primary archive log dir is not a goal to be achieved.
That thinking also applies to restorations of the primary, you want to
have as many logs available right away while under pressure, right?  I'm
sure I've seen somewhere in the best practices or metalink (or even the
docs) that many customers prefer to keep a wider range of logs than
"since the last backup."

>If my standby is NOT accepting or applying "shipped" logs should that
>there *rule* for not backing up and/or not deleting from the primary?
>As soon as late one night my primary archive log dir is full and db
>halts...that rule is out, right?

Yes, obviously if you have such a volume you have to watch out for

>Again I agree, but not in one script. Backup is backup...standby
>consistency is another script / logic / code.

I don't see such a boundary.  Recovery is recovery.  Standby is a subset
of recovery.

>>>I habitually keep days worth of archives after rman/backup.
>I will probably do the same, but "log age" is not a factor of having
>been shipped...or we found out the hard way also.

In the end it is an arbitrary judgement call.

Steven Patenaude wrote:

>have you needed an archive log after it has been accepted and applied
to >the standby?  If so, I'd like to know about it to guard against this
>scenario in the future.

No, what I had was managed recovery screw up applying a log, causing the
RFS process to kick back and stall my primary in a manner that required
a resetlogs to fix, despite all my and O supports efforts.  So, after
lots of deep thought, I decided a lot of slop in the process of deleting
logs is a good thing.  Deleting all logs after RMAN backup is not a good
thing.  YMMV.


>The standby monitoring scripts should let you know when the standby
isn't >applying logs anymore.  The production monitoring scripts should
let you >know if your directory is filling up.

Yes, exactly, one way or another.



Other related posts: