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

Joel,

>>[No] good atomic backup,
>>emptying the primary archive log dir is not a goal to be achieved.
>>have as many logs available right away while under pressure, right?=20
Yes, Yes, & Yes...I have to agree with you on this.

|| >If my standby is NOT accepting or applying "shipped" logs should that be
|| >there *rule* for not backing up and/or not deleting from the primary?=20
>>Yes, obviously if you have such a volume you have to watch out for
showstoppers.

I thought about this after left work last night. My logic is not good. I want to delete logs that have been shipped, regardless if they have been applied.
BUT, what if my network goes down...I can not even ship! If "shipping" becomes my "rule" for deleting, I could still find a full archive log dir under the right (bad) circumstances! I know that I could make the additional archive dest "optional", but I will likely end up deleting logs the standby still needs. Seems there is not good (simple) solution at this point? Except as you pointed out, to leave more logs on the file system AND backup & retain backups...just in case.

I guess in the end monitoring the standby for "log application consistency" will validate you backup decision / parameters?

Anybody have a good outline, scripts for DG "log application consistency" monitoring?

>>the RFS process to kick back and stall my primary in a manner that
required a resetlogs to fix,=20
Scary!...Ugly!

>>a lot of slop in the process of deleting logs is a good thing.
Want to share that slop? :o)

Chris Marquez
Oracle DBA
HEYMONitor(tm) - heymonitor.com
"Oracle Monitoring & Alerting Solution"

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Joel Garry Sent: Tuesday, January 11, 2005 6:51 PM
To: oracle-l_at_freelists.org
Subject: RE: RMAN/DG - delete *ONLY* archive logs "already shipped to thestandby DataGuard database"?

Marquez, Chris wrote:

>I agree, best to delete after the whole process is complete...applied
to
>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
be
>there *rule* for not backing up and/or not deleting from the primary?=20
>As soon as late one night my primary archive log dir is full and db=20
>halts...that rule is out, right?

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

>Again I agree, but not in one script. Backup is backup...standby=20
>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=20
>been shipped...or applied...as 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.

jg

--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l