RE: Streams arch log recover scenario
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <prabhu_adam@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 16 Mar 2011 11:18:50 -0400
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Prabhu Krishnaswamy
Sent: Wednesday, March 16, 2011 9:56 AM
To: oracle-l@xxxxxxxxxxxxx
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
Other related posts: