RE: looking for best practice for dealing with archivelogs on standby

From: <>
Date: Mon, 11 Oct 2010 09:00:04 -0400
Message-ID: <>

Yes - it all depends on your approach to paranoia on this subject.

Archive logs are ultimately the last piece to doing a recovery and a single point of failure.

You can go back and get older data files but you will still need the archive logs to do recovery

And that is why in some situations people have multiple destinations and multiple backups.

If you are comfortable that you have enough of these and can get these to the standby destination when needed I suppose you don't need to backup and you can delete them.

But as Andrew said most people I know back them up.    

[] On Behalf Of Andrew Kerber Sent: Monday, October 11, 2010 8:52 AM
Subject: Re: looking for best practice for dealing with archivelogs on standby  

I have always backed them up, and most people I know do also. I can't think of any real use for them, other than as useful for a belt and suspenders approach to data recovery and backup. Some of us get a little paranoid about having backups, and I have always thought more was better than less....

On Mon, Oct 11, 2010 at 7:43 AM, <> wrote:

Is the idea to backup archivelogs generated from standby database when doing LGWR apply from primary to standby?

I am thinking there is no use in backing them up but just remove them
(or use the rman configure archivelog deletion policy to applied on
standby) option.

Thoughts from those of you who are running standby would be greatly appreciated.

environment:, linux, using dg broker.

thanks, joe

Joe Testa, Oracle Certified Professional Senior Engineering & Administration Lead
(Work) 614-677-1668
(Cell) 614-312-6715
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Please visit our website at for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information. --
Received on Mon Oct 11 2010 - 08:00:04 CDT

Original text of this message