RE: Flashback database versus RMAN
- From: "Jeremiah Wilton" <jeremiah@xxxxxxxxxxx>
- To: <kevin.lidh@xxxxxxxxx>, <niall.litchfield@xxxxxxxxx>
- Date: Thu, 21 Feb 2008 10:13:47 -0800
Kevin Lidh wrote:
> ...recently we had a failover situation with one of our DG primary
> databases. We were able to flashback the original primary to the SCN
> where the failover occurred and start it up as the standby... Then
> we switched back seamlessly. It was very handy.
I think this just points out one of the reasons database flashback was a
source of concern for the original poster. Although you were able to flash
back the former primary back to the failover SCN, that must have meant
throwing out all changes that had been made on the original primary
subsequent to that SCN. Perhaps the number of such changes was very low for
you. In failover situations, the primary may not be taking changes anyway,
but a lot depends on how contemporary the logs on the standby are. For
businesses with continuous operations, there are few situations in which any
such data loss would be acceptable.
Database flashback flashes the whole database back, negating all changes
made subsequent to the SCN to which you revert. Much literature touts
flashback as a good way to back out logical corruption, such as application
and user-initiated data loss. However, because of the necessity of data
loss when using DB flashback, I question how realistic it is for the vast
majority of deployments.
Most people responding to this thread have stated they use DB flashback for
test labs and benchmarking, to allow repeatable activities on a single
database from a known starting point. I also use it in a similar manner
alongside DB replay, so that when I am testing a particular change such as
an initialization parameter, I can test with identical workload iteratively
with a variety of settings, from the starting point of that workload.
Regards,
Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net
--
//www.freelists.org/webpage/oracle-l
Other related posts:
