Something else you might want to consider is why your primary failed in the first place. In any High-Availability/Disater Recovery scenario, the database is or can be a single point of failure. If you have a corrupt database and you're replicating via storage snapshots or using DataGuard with automatic fail-over, you run the risk of ending up with a corrupt DB at both locations requiring a lot of downtime to restore to point-in-time. If you have an active/passive DataGuard setup with a delay in applying logs for instance, you have a chance to bring the DR site current until just prior to the failure before you open the DB for use. I had a similar requirement at my previous employer and we delayed log application for 60 minutes. It was a 7+TB enterprise SAP DB processing a LOT of data. We were located in Florida and particularly for hurricane season, maintained a DR site outside Atlanta. We practiced failing over at least twice a year, and actually switched over at other times for maintenance reasons. Applying the outstanding logs took 5 minutes at the most and we were generally able to perform a complete switchover in just under 10 minutes. On Wed, Aug 31, 2011 at 10:58 AM, Sanjay Mishra <smishra_97@xxxxxxxxx>wrote: > Jason > > Yes it was my mistake to say no downtime but actually it is least downtime. > Ofcourse we can use Fast Start failover to minimize the switcover/failover > time based on business requirements and avoid some manual intervention. > > So What I can see is the Dataguard and Storage based replication as two > main choices but want to see how Storage based can provide more better > solution over dataguard on technical side and not on financial terms and > what is best practices in critical online environment > > TIA > Sanjay > > ------------------------------ > *From:* jason arneil <jason.arneil@xxxxxxxxx> > *To:* saurabhmanroy@xxxxxxxxx > *Cc:* oracle-l@xxxxxxxxxxxxx > *Sent:* Wednesday, August 31, 2011 8:47 AM > > *Subject:* Re: Oracle DR Solution > > One drawback with the dataguard route is the "… no loss or downtime" > requirement. > > Sure data guard and be configured to ensure no data loss, but it can't give > you *no *downtime. > > Is that no downtime really a requirement? If you are serious about that, > you have to go to some form of Active - Active setup across datacentres, > with stretched RAC as a possibility. > > I'd also argue that there are few businesses that really in a catastrophic > scenario can't afford a handful of minutes to enact a failover. > > jason. > > -- > http://jarneil.wordpress.com > > > > On 31 Aug 2011, at 11:35, saurabh manroy wrote: > > Extended/Stretch RAC is a low cost but rather incomplete DR solution. > Low Cost: In-terms of number of resources need to maintain the environment. > DataGuard maintenance needs additional skills (apart from knowing RAC). > Also, not to forget licensing costs for DataGuard. > Incomplete: Distance between nodes of cluster is still a major factor. > Though 11g comes with preffred mirror read options, internode communication > would still be an issue over long distance. So, less distance between nodes > means, both sites would likely stop functioning in situations of: flood, > earthquake etc. > > Since Cost is not an issue for Sanjay, Primary DB as a RAC cluster and > Standby DB also a RAC cluster would be a better solution in my opinion. > > Regards, > Saurabh Manroy > http://smanroy.wordpress.com > > > the reader of this email (and attachments) is not the intended recipient, > you are hereby notified that any dissemination, distribution or copying of > this communication is strictly prohibited. Please notify the sender of the > error and delete the e-mail you received. Thank you.**** > ** ** > *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Sanjay Mishra > *Sent:* Tuesday, August 30, 2011 3:28 PM > *To:* oracle-l@xxxxxxxxxxxxx > *Subject:* Oracle DR Solution**** > ** ** > Hi**** > ** ** > I am looking to see what is the best option to have DR solution that can be > Primary with no loss or downtime. Looking for best practices even it is > expensive solution. Appreciate for any document or link as I am sure lots > has done work on it. One of the requirement is that database is around 10Tb > and transaction logs will be be not more than 50G in an hour.**** > ** ** > 1. Can see 11g Active Dataguard which can be used for Reporting as well as > DR solution**** > 2. Storage Replication**** > ** ** > Rgds**** > Sanjay**** > > This email and any attachments are confidential and may also be privileged. > If you are not the addressee, do not disclose, copy, circulate or in any > other way use or rely on the information contained in this email or any > attachments. If received in error, notify the sender immediately and delete > this email and any attachments from your system. Emails cannot be guaranteed > to be secure or error free as the message and any attachments could be > intercepted, corrupted, lost, delayed, incomplete or amended. Standard > Chartered PLC and its subsidiaries do not accept liability for damage caused > by this email or any attachments and may monitor email traffic. > > Standard Chartered PLC is incorporated in England with limited liability > under company number 966425 and has its registered office at 1 Aldermanbury > Square, London, EC2V 7SB. > > Standard Chartered Bank ("SCB") is incorporated in England with limited > liability by Royal Charter 1853, under reference ZC18. The Principal Office > of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In > the United Kingdom, SCB is authorised and regulated by the Financial > Services Authority under FSA register number 114276. > > If you are receiving this email from SCB outside the UK, please click > http://www.standardchartered.com/global/email_disclaimer.html to refer to > the information on other jurisdictions. > > > > > -- > Niall Litchfield > Oracle DBA > http://www.orawin.info > > > > > >