http://technology.amis.nl/2008/08/29/recovering-very-large-databases-in-the-least-amount-of-time/?utm_source=rss&utm_medium=rss&utm_campaign=recovering-very-large-databases-in-the-least-amount-of-time Fri, 12 Apr 2013 10:04:09 +0000 hourly 1 http://wordpress.org/?v=3.5.1 http://technology.amis.nl/2008/08/29/recovering-very-large-databases-in-the-least-amount-of-time/#comment-5437 Arnoud Wed, 17 Sep 2008 09:00:18 +0000 http://technology.amis.nl/blog/?p=3371#comment-5437 Alexander,
True, so true, however, what about the replication of corruptions? Obviously, one could consider flashback database for this. Still, my opinion is to have a separate database copy (to be (point-in-time) recovered before being switched to) is a safer method. Additionally, switching to a remote SAN requires additional work by other disciplines (OS/Storage management), whilst switching to a copy is solely done by DBA, which in effect is more efficient.
Arnoud

]]> http://technology.amis.nl/2008/08/29/recovering-very-large-databases-in-the-least-amount-of-time/#comment-5436 Alxeander 'sure' Podkopaev Wed, 03 Sep 2008 10:56:54 +0000 http://technology.amis.nl/blog/?p=3371#comment-5436 having “twice the amount of diskspace for your database” sound similar to “having two SAN with replication” to me. You switch to backup SAN and voila – you’re running you database again.

]]>