RE: flashback a physical standby database
- From: "Mathias Zarick" <Mathias.Zarick@xxxxxxxxxxxx>
- To: <stmontgo@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 21 Aug 2009 08:35:15 +0200
Hi Steve,
flashback logs are not propagated from primary to standby.
the standby database itself must be in standby mode and generates
its own set of flashback logs.
Standby Database can be in flashback mode and managed recovery mode.
The scenario with the guaranteed restore point just works.
It also has to be created on standby site.
HTH Mathias
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of steve montgomerie
Sent: Friday, August 21, 2009 5:12 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: flashback a physical standby database
A much belated follow up and thanks for all that posted suggestions.
Maybe a better description might help
On Friday an opps on a table - bad update
On Monday the error is caught and we can't flashback the table
So can I open the standby and then flash it back to Friday?
Although that would be cool the answer I found is no. The standby can't
be in sustained recovery and in flashback mode at the same time.
Flashnack logs are not propgated through DG so the standby has nothing
to flashback with.
I understand the bit about opening the standby, creating restore point,
test and flashback but that would not
work in my case as I wanted to flashback to a previous point in time
where flashback was not enabled.
Anyhow, if anything I can serve as a warning beacon to others. What I
did in the heat of the momeent
was to use rman to duplicate database to previous PIT and use the skip
tablespace option which seemed like a good idea at the time. What I now
know is that RMAN does this duplicate database restoring / recovering
all database files and then
opens up to drop the tablespaces that I provided in the skip tablespace
clause. - dooh doooh dooooooh! Why would it even bother to
restore/recover files that I told it to skip? Stooooopid RMAN.
What I should have done was copy system, undo, desired TS to another
server and then did PIT recovery on a smaller subset of the data. In
that way my restore would have involved 100G instead of the 600G and not
taken 5 hours.
Anyway, thanks for the all posts. The bit about using Flashback on
standby for testing will come in super handy for me in the future.
All the best
Steve
On Tue, Jul 21, 2009 at 2:38 PM, steve montgomerie <stmontgo@xxxxxxxxx>
wrote:
Can I flashback a physical standby?
Scenario is this..
opps update on table last friday.
Can't flashback the table ...snaphsot too old
I was thinking that I might be able to open the standby ,
flashback, get the data , flash forward, resume recovery
Or do I do TSPITR with RMAN on auxillary instance.
We are ...
10.2.0.4. RAC as primary with no rac on single instance physical
standby
OEL 4.5
Other related posts:
