RE: Flashback database versus RMAN

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

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