Re: Oracle DR Solution

  • From: Gaja Krishna Vaidyanatha <gajav@xxxxxxxxx>
  • To: Oracle-L List <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 31 Aug 2011 14:34:15 -0700

Greetings Hemant,

Not sure I fully understand what you mean by "GoldenGate is NOT a DR solution". 
Any DR site needs to be populated with some data replication method. And 
DataGuard and GoldenGate BOTH do just that, albeit in different ways. 

WIth Extended RAC, there is the issue of distance and thus I would classify it 
as an optimal "intra-data center HA" (within the same data center) option. 
Golden Gate and DataGuard both provide you the capability of "inter-data center 
HA" (across data centers) and also provide the ability to maintain DR sites. 
Extended RAC is a good option for a campus-based HA (ideally with distances not 
exceeding 10 km). Yes, I know what the documentation says with 100 km, but 
depending on the application, the segmentation of users across nodes (and their 
respective read/write workloads) and the interaction with the database buffer 
cache, inter-node communication can (and will) be an issue, as the distance 
between the nodes increase. Thus, I agree with some of the concerns voiced over 
implementing Extended RAC over long distances (even with dark fiber) due to 
latency issues that can exacerbate inter-node communication and in-turn can 
cause all sorts of downstream issues to the stability of the nodes in the 
cluster. If one has dealt with node-evictions due to cluster communication 
delays, you know exactly what I am referring to here.

Compare and contrast Extended RAC with Golden Gate or DG or 11g Active DG, and 
the distance between the data centers is usually NOT an issue. Given the same 
dark fiber network setup, latency for data replication between data centers 
does not cause "production database waits or delays" as data replication is 
asynchronous in nature. The only caveat is when one configures DG in 
synchronous mode, that care needs to be exercised again, as it relates to the 
distance between data centers. Hope this helps.

Cheers,

Gaja

Gaja Krishna Vaidyanatha,
CEO & Founder, DBPerfMan LLC
http://www.dbperfman.com
Phone - 001-650-743-6060
Co-author:Oracle Insights:Tales of the Oak Table - 
http://www.apress.com/book/bookDisplay.html?bID=314
Co-author:Oracle Performance Tuning 101 - 
http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766

On Aug 30, 2011, at 5:52 PM, Chitale, Hemant Krishnarao wrote:

>  
> Neither RAC  nor   GoldenGate is a DR solution.
>  
>  
> Sanjay has correctly listed the two options  (Active) DataGuard and 
> StorageBasedReplication (with Snapshots that allow opening a database 
> snapshot image).
>  
>   
> Hemant K Chitale 
> 
>  
> From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
> Behalf Of Michael Dinh
> Sent: Wednesday, August 31, 2011 6:44 AM
> To: 'smishra_97@xxxxxxxxx'; oracle-l@xxxxxxxxxxxxx
> Subject: RE: Oracle DR Solution
>  
> With no loss or down time, then I would think RAC/ Golden Gate.
>  
> Michael Dinh
>  
> Disparity Breaks Automation (DBA)
>  
> NOTICE OF CONFIDENTIALITY - This material is intended for the use of the 
> individual or entity to which it is addressed, and may contain information 
> that is privileged, confidential and exempt from disclosure under applicable 
> laws.  BE FURTHER ADVISED THAT THIS EMAIL MAY CONTAIN PROTECTED HEALTH 
> INFORMATION (PHI). BY ACCEPTING THIS MESSAGE, YOU ACKNOWLEDGE THE FOREGOING, 
> AND AGREE AS FOLLOWS: YOU AGREE TO NOT DISCLOSE TO ANY THIRD PARTY ANY PHI 
> CONTAINED HEREIN, EXCEPT AS EXPRESSLY PERMITTED AND ONLY TO THE EXTENT 
> NECESSARY TO PERFORM YOUR OBLIGATIONS RELATING TO THE RECEIPT OF THIS 
> MESSAGE.  If 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.

Other related posts: