Re: Oracle DR Solution

  • From: Sanjay Mishra <smishra_97@xxxxxxxxx>
  • To: "jason.arneil@xxxxxxxxx" <jason.arneil@xxxxxxxxx>, "saurabhmanroy@xxxxxxxxx" <saurabhmanroy@xxxxxxxxx>
  • Date: Wed, 31 Aug 2011 08:58:42 -0700 (PDT)

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
>>
>

Other related posts: