RE: Streams arch log recover scenario

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 16 Mar 2011 11:18:50 -0400
Message-ID: <042001cbe3ed$7510f130$5f32d390$_at_rsiz.com>



The planned action by the DBA team in the event the capital planning process has failed and you reach a situation where production archives are full and you cannot move them elsewhere to clean out room should be dictated by which action will cost the company the least amount of money to repair. And you left out the possibility of suspending all transactions once the archive destination is full and no more space remains to allocate on-line logs, which could potentially allow catching up on the target.  

Determination of the exact action in an exact situation when lack of equipment (or a temporary loss of telecom, as in the case of a remote target, where if it is important you should have an alternate route available, possibly including trucknet) is beyond the scope of control of most DBAs. Explaining the options up through the management team well before such a situation occurs should get you a triage list. They should be able to guide you in the Sophie's choice they have forced you into, but more likely they will give you the equipment you need or tell you when you have reached a cost of insurance against unlikely scenarios that exceeds the value to the enterprise.  

Of course simply having more space available and changing the archive destination for new archives to that place should work. Any process that doesn't follow the change around is a bug. And adding more online logs can help you manage through getting more disk attached.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Prabhu Krishnaswamy
Sent: Wednesday, March 16, 2011 9:56 AM
To: oracle-l_at_freelists.org
Subject: Streams arch log recover scenario  

Lists,  

We have the following scenario to be tested....  

How to recover from FULL archive destination situation when  

Target is down or streams replication is so slow that RMAN can't delete archives since they needed by streams.
RMAN doesn't allow deletion of any archives if they are needed for streams replication  

What should be the action from DBAs  

  1. compromise Source db by manually moving or removing archives since RMAN can't delete it, it will allow you to backup though
  2. compromise the streams setup and Target by disabling streams replication, but will that allow RMAN to delete archives or you need additional steps ? Or additional action needed

Any insight on this will be highly appreciated !!!  

Thank You,
Prabhu  

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Mar 16 2011 - 10:18:50 CDT

Original text of this message